Facebook
TwitterThis dataset is comprised of the .prj and .cvf files used to build the database for the Virus Particle Exposure in Residences (ViPER) Webtool, a single zone indoor air quality and ventilation analysis tool developed by the National Institute of Standards and Technology (NIST).
Facebook
TwitterAttribution 4.0 (CC BY 4.0)https://creativecommons.org/licenses/by/4.0/
License information was derived automatically
File set contains HEC-RAS associated files for Taiacupeba Sediment Model, including main project file (.prj), geometric data (.g0*), steady flow data (.f0*), quasi-unsteady flow data (.q0*), sediment boundary conditions (.s0*) and simulation plans (.p0*). Computational results are not available, one should download files and run them locally.
Facebook
TwitterThis data release provides aerial images acquired through the National Agricultural Imagery Program (NAIP) used to test a method for inferring image acquisition time from shadow orientation. For many applications, such as linking remotely sensed data to streamflow recorded at a gaging station, knowing the time an image is acquired is important, but such metadata often is not available. The sundial method is a simple means of inferring image acquisition time from shadow orientation. Images with known acquisition times are used to test the approach. The file SundialDataReleaseNAIP.csv contains image metadata, shadow measurements, and inferred image acquisition times based on the sundial method. The difference between the known acquisition times of the aerial images and those inferred via the sundial technique is used to assess the accuracy of the method. Please refer to the entity and attribute section of the metadata for further detail regarding this file. To facilitate plotting, this information is also provided in a shapefile that contains the same attributes as the file SundialDataReleaseNAIP.csv but represents the digitized shadows as line features. The shapefile is named ShadowLinesNAIP.shp and is packaged in a zip file named ShadowLinesNAIP.zip. The zip file also contains a .prj file that defines the coordinate reference system of the shapefile as geographic coordinates (latitude and longitude) in the NAD83 datum. The file SundialImagesNAIP.zip contains 6 NAIP aerial images with known acquisition times that were used to test the sundial method. Each image is provided in a GeoTIFF format that includes embedded spatial referencing information. Users are advised to thoroughly read the metadata file associated with this data release to understand the appropriate use and limitations of the data and code provided herein. Any use of trade, firm, or product names is for descriptive purposes only and does not imply endorsement by the U.S. Government.
Facebook
TwitterThis dataset provides shapefile of outlines of the 68 lakes where temperature was modeled as part of this study. The format is a shapefile for all lakes combined (.shp, .shx, .dbf, and .prj files). This dataset is part of a larger data release of lake temperature model inputs and outputs for 68 lakes in the U.S. states of Minnesota and Wisconsin (http://dx.doi.org/10.5066/P9AQPIVD).
Facebook
TwitterGIS 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:
ftp://ftp.agrc.utah.gov/UtahSGID_Vector/UTM12_NAD83/CADASTRE/LIR_ParcelSchema.zip
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 systems
COUNTY_NAME Text 20 - County name including spaces ex. BOX ELDER
COUNTY_ID (expected) Text 2 - County ID Number ex. Beaver = 1, Box Elder = 2, Cache = 3,..., Weber = 29
ASSESSOR_SRC (expected) Text 100 - Website URL, will be to County Assessor in most all cases ex. webercounty.org/assessor
BOUNDARY_SRC (expected) Text 100 - Website URL, will be to County Recorder in most all cases ex. webercounty.org/recorder
DISCLAIMER (added by State) Text 50 - Disclaimer URL ex. gis.utah.gov...
CURRENT_ASOF (expected) Date - Parcels current as of date ex. 01/01/2016
PARCEL_ID (expected) Text 50 - County designated Unique ID number for individual parcels ex. 15034520070000
PARCEL_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, Other
TAX_DISTRICT (expected, where applicable) Text 10 - The coding the county uses to identify a unique combination of property tax levying entities ex. 17A
TOTAL_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. 332000
LAND _MKT_VALUE (expected) Decimal - The market value of the parcel's land as determined by the Assessor for the most current tax year ex. 80600
PARCEL_ACRES (expected) Decimal - Parcel size in acres ex. 20.360
PROP_CLASS (expected) Text 100 - Residential, Commercial, Industrial, Mixed, Agricultural, Vacant, Open Space, Other ex. Residential
PRIMARY_RES (expected) Text 1 - Is the property a primary residence(s): Y'(es), 'N'(o), or 'U'(nknown) ex. Y
HOUSING_CNT (expected, where applicable) Text 10 - Number of housing units, can be single number or range like '5-10' ex. 1
SUBDIV_NAME (optional) Text 100 - Subdivision name if applicable ex. Highland Manor Subdivision
BLDG_SQFT (expected, where applicable) Integer - Square footage of primary bldg(s) ex. 2816
BLDG_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. 2
FLOORS_INFO (expected, where applicable) Text 100 - Note for how floors are counted by the County ex. Only above grade floors are counted
BUILT_YR (expected, where applicable) Short - Estimated year of initial construction of primary buildings ex. 1968
EFFBUILT_YR (optional, where applicable) Short - The 'effective' year built' of primary buildings that factors in updates after construction ex. 1980
CONST_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)
Facebook
TwitterThis dataset provides shapefile outlines of the 7,150 lakes that had temperature modeled as part of this study. The format is a shapefile for all lakes combined (.shp, .shx, .dbf, and .prj files). A csv file of lake metadata is also included. This dataset is part of a larger data release of lake temperature model inputs and outputs for 7,150 lakes in the U.S. states of Minnesota and Wisconsin (http://dx.doi.org/10.5066/P9CA6XP8).
Facebook
TwitterAttribution 4.0 (CC BY 4.0)https://creativecommons.org/licenses/by/4.0/
License information was derived automatically
Description: This zipfile contains three shapefiles of linear geometries showing channel networks across the SAFE landscape.
RIVERS_UTM.shp: From Igor Lysenko's SAFE pack, this is a river network with two areas, covering Maliau and the area around the SAFE experimental region. The network density is much higher in Maliau than SAFE and the channel network around SAFE is not complete. This is projected in UTM50N WGS84. LFEriver_SL.shp: This is provided (by Sarah Luke?) through Clare Wilkinson's GIS files and adds a critical missing stream for the Logged Forest Edge (LFE) catchment. This is projected in UTM50N WGS84. all_rivers.shp: This is provided through Clare Wilkinson's GIS files and provides streams for a single region covering Danum and the SAFE experimental region but not sampled watersheds in Oil Palm plantations to the south of SAFE. The original file is missing projection information (no .prj file) but other files in the same dataset are projected in RSO Timbalai 1948 and using this projection fits with the context of other data. The version uploaded onto Zenodo has been reprojected into UTM50N WGS84.Although the files are not consistent, they do contain channels and channel data that are referenced in some studies. The provenance of these files are unknown, although the following suggests that they may be traced using GPS or from imagery:
Incomplete coverage within the regions they cover. Treatment of larger rivers, changing from a single line feature showing the stream centreline (?) to double lines showing the river banks. Variation in network density: the western edge of all_rivers.shp shows a vertical band about 4 km wide of higher stream density than the rest of the region; RIVERS_UTM.shp shows marked differences in stream density between SAFE and Maliau.
Project: This dataset was collected as part of the following SAFE research project: SAFE CORE DATA XML metadata: GEMINI compliant metadata for this dataset is available here Files: This dataset consists of 2 files: SAFE_Alternative_Stream_network_metadata.xlsx, Preexisting_SAFE_river_files.zip SAFE_Alternative_Stream_network_metadata.xlsx This file only contains metadata for the files below Preexisting_SAFE_river_files.zip Description: Contains three shapefiles of channel networks. This file contains 3 data tables:
Feature properties (described in worksheet LFEriver_SL) Description: Field descriptions for shapefile properties Number of fields: 1 Number of data rows: Unavailable (table metadata description only). Fields:
Id: Identity of river (Field type: id)
Feature properties (described in worksheet RIVERS_UTM) Description: Field descriptions for shapefile properties Number of fields: 1 Number of data rows: Unavailable (table metadata description only). Fields:
NAME: Local name of segment (Field type: comments)
Feature properties (described in worksheet all_river_UTM50N_WGS84) Description: Field descriptions for shapefile properties Number of fields: 10 Number of data rows: Unavailable (table metadata description only). Fields:
FNODE_: Unknown (Field type: numeric) TNODE_: Unknown (Field type: numeric) LPOLY_: Unknown (Field type: numeric) RPOLY_: Unknown (Field type: numeric) LENGTH_MET: Length of channel segment in metres (Field type: numeric) RIV_YSC_: Unknown (Field type: numeric) RIV_YSC_ID: Unknown (Field type: numeric) CODE: Unknown (Field type: numeric) NAME: Local name of segment (Field type: comments) AREA: Local area of segment (Field type: comments)
Date range: 2010-10-01 to 2019-10-01 Latitudinal extent: 4.0223 to 5.9761 Longitudinal extent: 116.0242 to 117.9758
Facebook
TwitterAttribution 4.0 (CC BY 4.0)https://creativecommons.org/licenses/by/4.0/
License information was derived automatically
Here we produced the first 10 m resolution urban green space (UGS) map for the main urban clusters across 371 major Latin American cities as of 2017. Our approach applied a supervised classification of Sentinel-2 satellite imagery and UGS samples derived from OpenStreetMap (OSM). The overall accuracy of this UGS map in 11 randomly selected cities was 0.87, evaluated by independently collected validation samples (‘ground truth’). We further improved mapping quality through a visual inspection and additional sample collection. The resulting UGS map enables studies to measure area, spatial configuration, and human exposures to UGS, facilitating studies about the relationship between UGS and human exposures to environmental hazards, public health outcomes, and environmental justice issues in Latin American cities.UGS in this map series includes grass, shrub, forest, and farmland, and non-UGS included buildings, pavement, roads, barren land, and dry vegetation.The UGS map series includes three sets of files:(1) binary UGS maps at 10 m spatial resolution in GEOTIFF format (UGS.zip), with each of the 371 cities being an individual map. Mapped value of 1 indicates UGS, 0 indicates non-UGS, and no data (with value of -32768) indicates areas outside the mapped boundary or water bodies;(2) a shapefile of mapped boundaries (Boundaries.zip). The boundary file contains city name, country name and its ISO-2 country code, and an ID field linking each city's boundary to the corresponding UGS map.(3) .prj files containing projection information for the binary UGS maps and boundary shapefile. The binary UGS maps are projected with World Geodetic System (WGS) 84 / Pseudo-Mercator projected coordinate system (EPSG: 3857), and the boundary shapefile is projected with WGS 1984 geographic coordinate system (EPSG: 4326)Reference: A 10 m resolution urban green space map for major Latin American cities from Sentinel-2 remote sensing images and OpenStreetMap, published by Scientific Data [link].Citation: Ju, Y., Dronova, I., & Delclòs-Alió, X. (2022). A 10 m resolution urban green space map for major Latin American cities from Sentinel-2 remote sensing images and OpenStreetMap. Scientific Data, 9, Article 1. https://doi.org/10.1038/s41597-022-01701-y
Facebook
TwitterThis dataset provides shapefile outlines of the 881 lakes that had temperature modeled as part of this study. The format is a shapefile for all lakes combined (.shp, .shx, .dbf, and .prj files). A csv file of lake metadata is also included. This dataset is part of a larger data release of lake temperature model inputs and outputs for 881 lakes in the U.S. state of Minnesota (https://doi.org/10.5066/P9PPHJE2).
Facebook
TwitterLarge-scale_prediction_archiveThis compressed archive includes multiple other files including data files (in .rdata format) GIS shapefiles (in folders with the associated .shp, .shx, .dbf, and .prj files for each map) and an R script that will run all analyses and plot all figures. Specific descriptions of each file are supplied in the README.TXT file.
Facebook
TwitterU.S. Government Workshttps://www.usa.gov/government-works
License information was derived automatically
The Columbia River Light Detection and Ranging (LiDAR) survey project was a collaborative effort to develop detailed high density LiDAR terrain data for the US Army Corps of Engineers (USACE). The LiDAR will be used to support hydraulic modeling work associated with proposed 2014 Columbia River treaty negotiations. The dataset encompasses approximately 2836 square miles of territory in portions of Oregon, Washington, Idaho and Montana within the Columbia River drainage. This survey was under the jurisdiction of three Corps districts: Portland (CENWP), Seattle (CENWS), and Walla Walla (CENWW). CENWP was the project lead and primary contracting organization. Bare earth point data are classified as either ground (2), model key point (8) or water (9) and represent the earth's surface with all vegetation and human-made structures removed. Model key points were generated to represent the bare earth surface within a 0.07 m tolerance. Ground points (class 2) are the remaining ground points not classed as model key. Both ground and model key classes are needed for display of all bare earth points. Water classification was used for those bare earth/ground classified points that fell inside a water boundary as determined using softcopy photogrammetry with stereograms generated from LiDAR intensities. All remaining points received the default classification (1). In some areas of heavy vegetation or forest cover, there may be relatively few ground points in the LiDAR data. The RMSE of the data for open, hard-packed surfaces is 0.046 meters as assessed from 40,266 ground survey (real time kinematic) points taken on hard-packed road surfaces. This value is representative of anticipated accuracies in open, evenly sloped or flat terrain where maximum point densities were achieved. The project was completed for the US Army Corps of Engineers, Portland District, to support hydraulic modeling related to the ACOE Columbia River Treaty project. Data acquisition, bare earth processing, and development of final tiled LiDAR deliverables and DEM's was performed by Watershed Sciences, Inc. Overall project management, photogrammetric quality control review using LiDAR stereograms, water delineation and breakline development was performed by David C. Smith & Associates, Inc. Professional Surveyor oversight of ground control data, ground control data processing and ground control publication was performed by David Evans and Associates, Inc. Final quality control review in ArcGIS of all final deliverables, including preparation of point density rasters and reach based geo-databases incorporating all deliverables, was performed by CC Patterson and Associates. NOTE ON DATUM ISSUES: All ground control and subsequent LiDAR data deliverables were developed and delivered at NAD '83 CORS 96 horizontal and NAVD '88 Geoid '09 vertical datums as processed in OPUS-DB. Due to limitations in the transformations supported by ESRI, NAD '83 and NAVD '88 datums were temporarily assigned to the ESRI deliverables and ESRI .prj file even though the actual coordinate values in the data files are at the original NAD '83 CORS 96 and NAVD '88 Geoid '09 datums. In many instances, a temporary assignment of NAD '83 HARN or HPGN may better approximate local conditions. Plain NAD '83 was used for the primary deliverable in order to avoid any implication of higher precision; however, the user may want to evaluate other approximations for specific applications. At such time as ESRI includes support for NAD '83 CORS '96, the temporary NAD '83 assignment in the .prj file should be replaced with NAD '83 CORS '96 without further reprojection. The NOAA Office for Coastal Management has converted the data to ellipsoid heights (using Geoid09) and NAD 83 geographic coordinates for data storage and Digital Coast provisioning purposes.
Facebook
TwitterAttribution 4.0 (CC BY 4.0)https://creativecommons.org/licenses/by/4.0/
License information was derived automatically
Dataset contains the final spatial layers used in our cumulative impact maps. These layers include the individual stressor and seagrass habitat layers. All spatial intensity layers are .asc files with an associated .prj file. Reading the .asc file into R will automatically read in the information within the .prj file if both files are in the same folder location."SG_seagrass_only" = Spencer Gulf seagrass habitat layer"Poll" = Pollution"ES_mean_for_manuscript" contains the effect sizes for each stressor and stressor pair. For details on how these were calculated, see 'Stockbridge et al 2020' (doi: 10.1038/s41598-020-68801-w)
Facebook
TwitterAttribution 4.0 (CC BY 4.0)https://creativecommons.org/licenses/by/4.0/
License information was derived automatically
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)
Facebook
TwitterThese files represent the model output from ANUGA, generated as the channelized condition to simulate the flow through washout channels at San Jose Island, TX during hurricane Harvey (2017). The files included the modeled water depth, velocity, and stage. The file naming convention is "variable_large_11_timestep", indicating the model output type (depth, velocity, or stage) for the simulation type: "initiated with channels, large channels only, and the 11th model run", and the time step of the output. The publication includes figures which are made with output from the 350th time step. The .prj file type can apply to all .asc files.
Facebook
TwitterAttribution 4.0 (CC BY 4.0)https://creativecommons.org/licenses/by/4.0/
License information was derived automatically
Distribution map of Persian walnut (Juglans regia)These maps were produced by combining numerous and heterogeneous data collected from atlas monographs providing complete species distribution maps, from national to regional atlases, occurrence geo-databases, scientific and grey literature.The maps were created using ESRI shapefiles (*.shp, *.shx, *.dbf, *.prj files) archived in the ZIP file. Species range is mapped with polygon features (name suffix "plg"), which define continuous areas of occupancy of the species, and with point features (name suffix "pnt"), which identify more fragmented and isolated populations. If synanthropic occurrences are reported outside the species natural range, additional point and/or polygon shapefiles are also present (suffix "syn").Polygon borders delimiting species ranges are generalized across the mainland and sea boundaries. This offers the possibility to mask sea areas or to clip and extract the terrestrial range parts using GIS data layers of the users' choice. An additional version of polygon ranges are clipped with a coastline (name suffix "clip"), which have been derived from Natural Earth dataset "Admin 0 - Countries" 1:50M version 4.1.0 (https://www.naturalearthdata.com).Please cite as:Caudullo, G., Welk, E., San-Miguel-Ayanz, J., 2017. Chorological maps for the main European woody species. Data in Brief 12, 662-666. DOI: doi.org/10.1016/j.dib.2017.05.007Additional information and used references are on 'supplementary materials' document:https://doi.org/10.6084/m9.figshare.5091901Chorological maps are part of the "European Atlas of Forest Tree Species" project:https://w3id.org/mtv/FISE-Comm/v01
Facebook
TwitterAttribution 4.0 (CC BY 4.0)https://creativecommons.org/licenses/by/4.0/
License information was derived automatically
The data are organized as a set of ESRI shapefiles (*.shp, *.shx, *.dbf, *.prj files) mapping the distribution ranges of the main European tree and shrub species. For each species and in some cases subspecies, one or more shapefiles have been created containing: a) polygon features (name suffix “plg”), which define continuous areas of occupancy of the species range and b) point features (name suffix “pnt”), which identify more fragmented and isolated populations. For species with reported synanthropic occurrences outside the natural range, an additional point and/or polygon shapefile has also been created (suffix “syn”). The polygon borders delimiting the range have been generalized across the mainland and sea boundaries. Clipping to a specific coastline has been avoided, as this can vary considerably in its geometry depending on scale and precision of the respective source. This offers the possibility to mask sea areas, or to clip and extract the species’ terrestrial range parts using GIS data layers of the users’ choice. Finally, an accompanying text document is included with the data, which provides more details on methodology and a list of all mapped species with related file names, taxonomical delimitation of the mapped species and references used to compile the respective chorological dataset.
Facebook
TwitterAttribution 4.0 (CC BY 4.0)https://creativecommons.org/licenses/by/4.0/
License information was derived automatically
Distribution map of Macedonian oak (Quercus trojana)
These maps were produced by combining numerous and heterogeneous data collected from atlas monographs providing complete species distribution maps, from national to regional atlases, occurrence geo-databases, scientific and grey literature.
The maps were created using ESRI shapefiles (*.shp, *.shx, *.dbf, *.prj files) archived in the ZIP file. Species range is mapped with polygon features (name suffix "plg"), which define continuous areas of occupancy of the species, and with point features (name suffix "pnt"), which identify more fragmented and isolated populations. If synanthropic occurrences are reported outside the species natural range, additional point and/or polygon shapefiles are also present (suffix "syn").
Polygon borders delimiting species ranges are generalized across the mainland and sea boundaries. This offers the possibility to mask sea areas or to clip and extract the terrestrial range parts using GIS data layers of the users' choice. An additional version of polygon ranges are clipped with a coastline (name suffix "clip"), which have been derived from Natural Earth dataset "Admin 0 - Countries" 1:50M version 4.1.0 (https://www.naturalearthdata.com).
Please cite as:
Caudullo, G., Welk, E., San-Miguel-Ayanz, J., 2017. Chorological maps for the main European woody species. Data in Brief 12, 662-666. DOI: doi.org/10.1016/j.dib.2017.05.007
Additional information and used references are on 'supplementary materials' document:
https://doi.org/10.6084/m9.figshare.5091901
Chorological maps are part of the "European Atlas of Forest Tree Species" project:
https://w3id.org/mtv/FISE-Comm/v01
Facebook
TwitterThis data set provides a grid of quads and projection information to be used for rover operations and the informal geographic naming convention for the regional geography of Oxia Planum. Both subject to update prior to the landed mission.Contents This data set contains 4 shapefiles and 1 zipped folder.OxiaPlanum_GeographicFeatures_2021_08_26. Point shapefile with the names of geographic features last updated at the date indicatedOxiaPlanum_GeographicRegions_2021_08_26. Polygon shapefile with the outlines of geographic regions fitted to the master quad grid and last updated at the date indicated.OxiaPlanum_QuadGrid_1km. Polygon shapefile of 1km quad that will be used for ExoMars rover missionOxiaPlanum_Origin_clong_335_45E_18_20N. The center point of the Oxia Planum as defined by the Rover Operations and Control center and origin point used for the Quad gridCRS_PRJ_Equirectangular_OxiaPlanum_Mars2000.zip. Zip folder containing the projection information use for all the data associated with this study. These are saved in the ESRI projection (.prj) and well know text formal (.wkt)Guide to individual filesFile name (example) Description OxiaPlanum_QuadGrid_1km.cpg Text display information OxiaPlanum_QuadGrid_1km.dbf Database file OxiaPlanum_QuadGrid_1km.prj Projection information OxiaPlanum_QuadGrid_1km.sbx Spatial index file OxiaPlanum_QuadGrid_1km.shp Shape file data <-Open this data in GiS with the other supporting files in the same directoryOxiaPlanum_QuadGrid_1km.shp.xml Symbolisation information OxiaPlanum_QuadGrid_1km.shx Geoprocessing history These data are provided with the following projection:Equirectangular_Mars_Oxia_Planum, Projection = Equidistant_Cylindrical, Datum = D_Mars_2000 Spheroid, Central meridian = 335.45Quad grid and contoursThe quad grid was created using the ArcPro 2.7 Grid Index Features Tool (Esri, 2021). The grid is a 121 × 120 array of 1000 m × 1000 m quads labelled ‘A1’ in the South West to ‘DP120’ in the North East. The grid covers the entire CTX mosaic and the lower left corner of quad BD50 coincides with the centre of the ROCC projection system at 335.45°E 18.20°N. Topographic contours were created at 25 m intervals from a CTX DEM down sampled to 100 m/pixel, with contours shorter than 1500 m in length were removed. Contours were smoothed using the PAEK algorithm at a tolerance of 200 m (USGS & MRCTR GIS Lab, 2018).Geographic regions A common geographical division and naming system for the Oxia Planum region is needed to allow ExoMars team members to communicate efficiently. Identifying and naming geographical locations and zones provides a spatial context for detailed observations, strategic planning and operations, and hypotheses testing. Differentiating geographic regionsWe divide Oxia Planum into 30 regions (Figure 2 and Table 3 from Fawdon et al 2021). This system of regions is a formalisation of the geographic differentiation demanded by discussions since the initial suggestion of Oxia Planum as a landing site in 2014 (ESA & The ExoMars 2018 Landing Site Selection Working Group (LSSWG), 2014) Each region is defined by a combination of topographic and or albedo changes in the HRSC and CTX data and that have needed to be talked about. Regions are smaller closer to the center of the landing site or where topography and albedo are more variable. This reflects the need to increase the fidelity of discussion where the rover is more likely to land or there are likely to have been more active geomorphic processes. As such these regions capture features pertaining to hypotheses about the paleo-environments being developed by the RSOWG and provide a natural framework to explore Oxia Planum. Naming geographic regionsThe regions were named in three ways: a number, a unique identifier, and a descriptive term. Unique identifiers were drawn from a list of Roman imperial and senatorial provinces at the largest geographic extent of the Roman empire in 117AD. This scheme was chosen because it has geographic and cultural ties throughout Europe and provides an appropriate number and variety of names. The descriptive terms (e.g., Planum, Lacus, etc) are those used in planetary toponomy (IAU, 1979). Names were selected to reflect the geography of the region (e.g., Caledonia has high elevation terrain in the northwest, Aegyptus has a large channel feature). Geographic locations within regions are also named. These names were drawn from a wider list of Roman towns or other relevant geographic locations with suitable, but process-agnostic, descriptive term (e.g., Alexandria Tholus named after the city in the ‘Aegyptus’ imperial province). These conventions have the capacity to expand this list as exploration of Oxia Planum continues.Although IAU recognised features (e.g., Malino crater) have also been included, all other names are informal. Informal naming of local features has been performed by previous Mars Rover mission teams. As has occurred during previous missions, some names will probably be replaced with formal IAU designations as the mission progresses.
Facebook
TwitterAttribution 4.0 (CC BY 4.0)https://creativecommons.org/licenses/by/4.0/
License information was derived automatically
This dataset contains supplemental data required to reproduce the results of the paper Interplay of river and tidal forcings promotes loops in coastal channel networks (in review at Geophysical Research Letters). We provide raw and extracted channel network data for 19 river deltas/coastal marsh sites. For each site, the following files are provided:
XXX_base.tif : the raw binary mask of the river channel network XXX_clipper.shp (and associated .dbf, .prj, .qpj, and .shx files) : polygon(s) used to clip the raw mask XXX_clipped.tif : the binary mask of the river channel network after being clipped by XXX_clipper.shp XXX_filled.tif : the binary mask after filling islands via the method specified in the paper XXX_inlet_nodes.shp (and associated .dbf, .prj, .qpj, and .shx files) : locations of the inlet nodes; used by RivGraph XXX_shoreline.shp (and associated .dbf, .prj, .qpj, and .shx files) : location of the shoreline; used by RivGraph XXX_links.json : GeoJSON file containing the geometries, connectivities, and widths of each link in the network XXX_nodes.json : GeoJSON file containing the locations of each node of the network process_XXX.py : the python script used to generate the above files
All files listed below (except .py files) are georeferenced (i.e. can be opened with QGIS, ArcGIS or another GIS). Exceptions to the provided files include:
Barnstable: no "base.tif" is provided. Use "filled.tif". GBM: some hand-cleaning was performed on "filled.tif". Mackenize: "clipper.shp" is not provided, but "clipped.tif" is. Mississippi: "clipper.shp" is not provided as the mask was made from a shapefile.
In order to run process_XXX.py, the RivGraph package will need to be installed. Instructions can be found at https://github.com/jonschwenk/RivGraph.
Facebook
TwitterAttribution 4.0 (CC BY 4.0)https://creativecommons.org/licenses/by/4.0/
License information was derived automatically
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)
Facebook
TwitterThis dataset is comprised of the .prj and .cvf files used to build the database for the Virus Particle Exposure in Residences (ViPER) Webtool, a single zone indoor air quality and ventilation analysis tool developed by the National Institute of Standards and Technology (NIST).