Mapped Large Forest Dynamics plot vertexs of 6 ha or larger located on Barro Colorado Island and Gigante, Panama, within the Barro Colorado Nature Monument. The layer contains the coordinates in UTM (WGS 84, Zone 17 North) and Decimal Degrees (WGS 84).You can find the polygons for each study plot in this layer.

Contains all the vertices for the Sherman's study Plot. The following is a description in spanish for the route along the vertices:Partiendo del Punto 1, con coordenadas UTM 612810,1026467 y tomando rumbo S 0.0 W por 400 metros para encontrar el Punto 2, con coordenadas UTM 612810,1026067. Partiendo del Punto 2, se sigue con rumbo S 90.0 W por 100 metros para encontrar el Punto 3, con coordenadas UTM 612710,1026067.Partiendo del Punto 3, se sigue con rumbo S 0.0 W por 40 metros hasta encontrar el Punto 4, con coordenadas UTM 612710,1026027. Partiendo del Punto 4, se sigue con rumbo S 90.0 W por 140 metros hasta encontrar el Punto 5 con coordenadas UTM 612570,1026027.Partiendo del Punto 5, se sigue con rumbo N 0.0 E por 140 metros hasta encontrar el punto 6, con coordenadas UTM 612570,1026167.Partiendo del Punto 6, se sigue con rumbo N 90.0 E por 140 metros hasta encontrar el Punto 7, con coordenadas UTM 612710,1026167.Partiendo del Punto 7, se sigue con rumbo N 0.0 E por 300 metros hasta encontrar el Punto 8, con coordenadas UTM 612710,1026467.Partiendo del Punto 8, se sigue con rumbo N 90. E por 100 metros hasta encontrar el Punto 1 (inicial.)

This dataset contains 63 shapefiles that represent the areas of relevance for each research project under the National Environmental Science Program Marine and Coastal Hub, northern and southern node projects for Rounds 1, 2 & 3.

Methods:
Each project map is developed using the following steps:
1. The project map was drawn based on the information provided in the research project proposals.
2. The map was refined based on feedback during the first data discussions with the project leader.
3. Where projects are finished most maps were updated based on the extents of datasets generated by the project and followup checks with the project leader.

The area mapped includes on-ground activities of the project, but also where the outputs of the project are likely to be relevant. The maps were refined by project leads, by showing them the initial map developed from the proposal, then asking them "How would you change this map to better represent the area where your project is relevant?". In general, this would result in changes such as removing areas where they were no longer intending research to be, or trimming of the extents to better represent the habitats that are relevant.

The project extent maps are intentionally low resolution (low number of polygon vertices), limiting the number of vertices 100s of points. This is to allow their easy integration into project metadata records and for presenting via interactive web maps and spatial searching. The goal of the maps was to define the project extent in a manner that was significantly more accurate than a bounding box, reducing the number of false positives generated from a spatial search. The geometry was intended to be simple enough that projects leaders could describe the locations verbally and the rough nature of the mapping made it clear that the regions of relevance are approximate.

In some cases, boundaries were drawn manually using a low number of vertices, in the process adjusting them to be more relevant to the project. In others, high resolution GIS datasets (such as the EEZ, or the Australian coastline) were used, but simplified at a resolution of 5-10km to ensure an appopriate vertices count for the final polygon extent. Reference datasets were frequently used to make adjustments to the maps, for example maps of wetlands and rivers were used to better represent the inner boundary of projects that were relevant for wetlands.

In general, the areas represented in the maps tend to show an area larger then the actual project activities, for example a project focusing on coastal restoration might include marine areas up to 50 km offshore and 50 km inshore. This buffering allows the coastline to be represented with a low number of verticies without leading to false negatives, where a project doesn't come up in a search because the area being searched is just outside the core area of a project.


Limitations of the data:
The areas represented in this data are intentionally low resolution. The polygon features from the various projects overlap significantly and thus many boundaries are hidden with default styling. This dataset is not a complete representation of the work being done by the NESP MaC projects as it was collected only 3 years into a 7 year program.

Format of the data:
The maps were drawn in QGIS using relevant reference layers and saved as shapefiles. These are then converted to GeoJSON or WKT (Well-known Text) and incorporated into the ISO19115-3 project metadata records in GeoNetwork. Updates to the map are made to the original shapefiles, and the metadata record subsequently updated.

All projects are represented as a single multi-polygon. The multiple polygons was developed by merging of separate areas into a single multi-polygon. This was done to improve compatibility with web platforms, allowing easy conversion to GeoJSON and WKT.

This dataset will be updated periodically as new NESP MaC projects are developed and as project progress and the map layers are improved. These updates will typically be annual.


Data dictionary:
NAME - Title of the layer
PROJ - Project code of the project relating to the layer
NODE - Whether the project is part of the Northern or Southern Nodes
TITLE - Title of the project
P_LEADER - Name of the Project leader and institution managing the project
PROJ_LINK - Link to the project metadata
MAP_DESC - Brief text description of the map area
MAP_TYPE - Describes whether the map extent is a 'general' area of relevance for the project work, or 'specific' where there is on ground survey or sampling activities
MOD_DATE - Last modification date to the individual map layer (prior to merging)


Updates & Processing:
These maps were created by eAtlas and IMAS Data Wranglers as part of the NESP MaC Data Management activities. As new project information is made available, the maps may be updated and republished. The update log will appear below with notes to indicate when individual project maps are updated:
20220626 - Dataset published (All shapefiles have MOD_DATE 20230626)


Location of the data:
This dataset is filed in the eAtlas enduring data repository at: data\custodian esp-mac-3\AU_AIMS-UTAS_NESP-MaC_Project-extents-maps

Spatial data layers of stream crossing point locations, cross-section polyline, centerline polyline, and bank polyline shapefiles have been developed for selected stream crossings in the Squannacook River basin, Massachusetts. The spatial data and calculated attribute values are model input data for U.S. Army Corps of Engineer’s Hydrologic Engineering Center’s River Analysis System (HEC-RAS) hydraulic models. The stream crossing point locations were derived from the North Atlantic Aquatic Connectivity Collaboration (NAACC) database. The stream channel cross-sections, centerlines, and bank polylines were derived using automated methods in a Geographic Information System (GIS) using ArcGIS Pro and Python programming language. The polyline shapefiles are Z-enabled and have elevation data derived from Light Detection and Ranging (lidar) Digital Elevation Models (DEM) for Z-coordinate vertex values in units of feet. The polyline shapefiles are also M-enabled and have profile stationing values for the M-coordinate vertex values in units of feet. The automated GIS processes delineated a series of stream channel cross-sections along lidar-derived stream centerlines and have stream channel bathymetry estimated from Massachusetts bankfull channel geometry equations (Bent and Waite, 2013). The bankfull equations were also used to derive stream bank polylines. This data release contains the following shapefiles in the Spatial_Data_Layers.zip file: 1. Stream_Crossing_Locations.shp - Esri point shapefile derived from the NAACC stream crossing database. 2. Stream_Crossing_Watersheds.shp - Esri polygon shapefile of lidar-derived watershed boundaries that estimate the upstream drainage area for each stream crossing location. 3. Model_Cross_Sections.shp - Esri Z- and M-enabled polyline shapefile of the cross-section data used for hydraulic model input. 4. Model_Flowpaths.shp - Esri Z- and M-enabled polyline shapefile of the stream centerline and stream bank line data used for hydraulic model input. References: Bent, G.C., and Waite, A.M., 2013, Equations for estimating bankfull channel geometry and discharge for streams in Massachusetts: U.S. Geological Survey Scientific Investigations Report 2013–5155, 62 p., http://dx.doi.org/10.3133/sir20135155

This feature class is made up of river and stream lines that represent flowlines and cartographic features such as stream centerlines and river banks in Sauk County, WI. The waterlines were digitized off of the Sauk County 2010 1-foot color ortho-imagery at a scale of 1:600. Spatial accuracy is therefore consistent across the entire county. Vertex density varies between streams depending on the sinuosity of that particular stream. Also, vertex density is intentionally higher within city and village boundaries.

(a) Seven main steps from 3D data acquisition and processing, feature extraction, data mining procedures (classifiers and feature selection) to possible applications of the method. (b–d) illustrations of feature extraction methods. (b) Section areas and section convolutions. (i) Tooth (upper molar of Rhinolophus blasii) is divided into 10 equal sections perpendicular to the z-axis. Upper and lower bounds (relative to the zApex) for every second section are given along the z-axis. (ii) Occlusal view with every second section highlighted in red, with areas and convolutions for each section. (c) Orientation patch count (OPC). (i) Surface of the tooth (upper molar of Felis silvestris) is grouped into surface vertices according to their orientation in the xy-plane (ii). (iii) Vertices are further grouped according to their 4-cell connectivity followed by (iv) exclusion of small patches. (v) The resulting OPC value is the final number of patches. (d) The effect of surface folding and elongation on surface relief. Relief is calculated by dividing the 3D surface area by its 2D projected area. A flat, unspecialized surface (i) has a relief of 1. If the surface is folded (ii), such as in Otomys irroratus, or elongated (iii), such as in Felis silvestris, its relief increases.

description: This dataset contains point features representing the approximate location of tax parcels contained in County Assessor tax rolls. Individual county data was integrated into this statewide publication by the Arkansas Geographic Information Office (AGIO). The Computer Aided Mass Appraisal (CAMA) systems maintained in each county are used to populate the database attributes for each centroid feature. The entity attribute structure conforms to the Arkansas Cadastral Mapping Standard. The digital cadastral data is provided as a publication version that only represents a snapshot of the production data at the time it was received from the county. Published updates may be made to counties throughout the year. These will occur after new data is digitized or updates to existing data are finished. Production versions of the data exist in the various counties where daily and weekly updates occur. Users should consult the BEGIN_DATE attribute column to determine the age of the data for a given county. This column reflects the date when AGIO received the data from the county. Only parcels with an associated Computer Assisted Mass Appraisal (CAMA) record are provided. This means a CAMA record may exist, but no point geometry or vice-versa. Cadastral data is dynamic by its nature; therefore it is impossible for any county to ever be considered complete. The data is NOT topologically enforced. As a statewide integrator, AGIO publishes the data but does not make judgment calls about where points or polygon lines are meant to be located. Therefore each county data set is published without topology rules being enforced. GIS Technicians use best practices such as polygon closure and vertex snapping, however, topology is not built for each county. Users should be aware, by Arkansas Law (15-21-504 2 B) digital cadastral data does not represent legal property boundary descriptions, nor is it suitable for boundary determination of the individual parcels included in the cadastre. Users requiring a boundary determination should consult an Arkansas Registered Land Surveyor (http://www.arkansas.gov/pels/search/search.php) on boundary questions. The digital cadastral data is intended to be a graphical representation of the tax parcel only. Just because a county is listed does NOT imply the data represents county wide coverage. AGIO worked with each county to determine a level of production that warranted the data was ready to be published. For example, in some counties only the north part of the county was covered or in other cases only rural parcels are covered and yet in others only urban parcels. The approach is to begin incremental publishing as production blocks are ready, even though a county may not have county wide coverage. Each case represents a significant amount of data that will be useful immediately. Users should consult the BEGIN_DATE attribute column to determine the age of the data for a given county. This date reflects when the data was received from the county. Digital cadastral data users should be aware the County Assessor Mapping Program adopted a phased approach for developing cadastral data. Phase One includes the production of a parcel centroid for each parcel that bears the attributes prescribed by the state cadastral mapping standard. Phase Two includes the production of parcel polygon geometry and bears the standard attributes. The Arkansas standard closely mirrors the federal Cadastral Core Data Standard established by the Federal Geographic Data Committee, Subcommittee for Cadastral Data. Counties within this file include: Arkansas, Ashley, Baxter, Boone, Carroll, Chicot, Clark, Clay, Columbia, Conway, Craighead, Crawford, Cross, Desha, Faulkner, Franklin, Hot Spring, Howard, Izard, Jackson, Jefferson, Lafayette, Lincoln, Little River, Logan, Lonoke, Madison, Mississippi, Montgomery, Nevada, Newton, Perry, Pike, Poinsett, Polk, Pope, Pulaski, Randolph, Saline, Sebastian, Stone, Van Buren, Washington and White.; abstract: This dataset contains point features representing the approximate location of tax parcels contained in County Assessor tax rolls. Individual county data was integrated into this statewide publication by the Arkansas Geographic Information Office (AGIO). The Computer Aided Mass Appraisal (CAMA) systems maintained in each county are used to populate the database attributes for each centroid feature. The entity attribute structure conforms to the Arkansas Cadastral Mapping Standard. The digital cadastral data is provided as a publication version that only represents a snapshot of the production data at the time it was received from the county. Published updates may be made to counties throughout the year. These will occur after new data is digitized or updates to existing data are finished. Production versions of the data exist in the various counties where daily and weekly updates occur. Users should consult the BEGIN_DATE attribute column to determine the age of the data for a given county. This column reflects the date when AGIO received the data from the county. Only parcels with an associated Computer Assisted Mass Appraisal (CAMA) record are provided. This means a CAMA record may exist, but no point geometry or vice-versa. Cadastral data is dynamic by its nature; therefore it is impossible for any county to ever be considered complete. The data is NOT topologically enforced. As a statewide integrator, AGIO publishes the data but does not make judgment calls about where points or polygon lines are meant to be located. Therefore each county data set is published without topology rules being enforced. GIS Technicians use best practices such as polygon closure and vertex snapping, however, topology is not built for each county. Users should be aware, by Arkansas Law (15-21-504 2 B) digital cadastral data does not represent legal property boundary descriptions, nor is it suitable for boundary determination of the individual parcels included in the cadastre. Users requiring a boundary determination should consult an Arkansas Registered Land Surveyor (http://www.arkansas.gov/pels/search/search.php) on boundary questions. The digital cadastral data is intended to be a graphical representation of the tax parcel only. Just because a county is listed does NOT imply the data represents county wide coverage. AGIO worked with each county to determine a level of production that warranted the data was ready to be published. For example, in some counties only the north part of the county was covered or in other cases only rural parcels are covered and yet in others only urban parcels. The approach is to begin incremental publishing as production blocks are ready, even though a county may not have county wide coverage. Each case represents a significant amount of data that will be useful immediately. Users should consult the BEGIN_DATE attribute column to determine the age of the data for a given county. This date reflects when the data was received from the county. Digital cadastral data users should be aware the County Assessor Mapping Program adopted a phased approach for developing cadastral data. Phase One includes the production of a parcel centroid for each parcel that bears the attributes prescribed by the state cadastral mapping standard. Phase Two includes the production of parcel polygon geometry and bears the standard attributes. The Arkansas standard closely mirrors the federal Cadastral Core Data Standard established by the Federal Geographic Data Committee, Subcommittee for Cadastral Data. Counties within this file include: Arkansas, Ashley, Baxter, Boone, Carroll, Chicot, Clark, Clay, Columbia, Conway, Craighead, Crawford, Cross, Desha, Faulkner, Franklin, Hot Spring, Howard, Izard, Jackson, Jefferson, Lafayette, Lincoln, Little River, Logan, Lonoke, Madison, Mississippi, Montgomery, Nevada, Newton, Perry, Pike, Poinsett, Polk, Pope, Pulaski, Randolph, Saline, Sebastian, Stone, Van Buren, Washington and White.

Red de puntos de precisión (vértices geodésicos) que son calculados usando las directrices del Sistema de Referencia Global. Dicha red se mide por medio de equipos de recepción satelital (GPS – GNSS) donde se capturan datos provenientes de la observación y seguimiento de cuerpos celestes y satélites artificiales que se consideran fijos en el espacio u orientadores para ubicarse en el entorno.

In December 2024, the Lower Mississippi-Gulf Water Science Center (LMGWSC) conducted comprehensive field surveys of Lake Pushmataha, a central Mississippi reservoir owned by the Mississippi Band of Choctaw Indians (MBCI) and named in honor of Chief Pushmataha. These surveys aimed to provide high-resolution spatial data to support the Bureau of Indian Affairs (BIA) in designing and implementing safety rehabilitation measures for Lake Pushmataha Dam. Bathymetric data collection took place from December 9 to 12 using a high-resolution multibeam mapping system (MBMS), which included a multibeam echosounder (MBES) and an inertial navigation system (INS) mounted on a 21-foot marine survey vessel following methodologies outlined by Huizinga (2018). To capture shallow areas inaccessible to the MBMS vessel, a single beam echosounder (SBES) and an INS were mounted on a Jon boat and used for additional mapping on December 13. Topographic data covering land elevations and positions within approximately 0.25 miles of Lake Pushmataha's shoreline were collected on December 10 and 11 using an unmanned aircraft system (UAS) equipped with a light detection and ranging (lidar) scanner. This portion of the survey was conducted by Phoenix Unmanned LLC, a specialized provider of remotely piloted aircraft with advanced remote sensing capabilities. The processed multibeam, single beam, and lidar datasets were merged and saved in compressed LASer file format (.laz) as three-dimensional (3D) point geometries in units of US survey feet, with classification codes following the American Society for Photogrammetry and Remote Sensing (ASPRS) lidar point standard (ASPRS, 2011; ASPRS, 2013). The merged dataset is provided with this data release projected in the Mississippi East State Plane coordinate system, with horizontal reference to the North American Datum of 1983 (NAD83, 2011 realization) and vertical reference to the North American Vertical Datum of 1988 (NAVD88). To facilitate evaluations of lake and dam morphology, points classified with code 2 (ground) and code 40 (bathymetric point) were extracted from the provided LAZ file to generate a Triangulated Irregular Network (TIN), which was exported in a Computer-Aided Design (CAD)-compatible format as a DXF (Drawing Exchange Format) file and included with this data release at the request of the BIA for their convenience. Additionally, a shapefile containing coverage polygons representing the approximate spatial extent of each survey method (single-beam, multibeam, or lidar) is included to aid in the interpretation and spatial context of the collected data. Summary of files included with this data release: LakePushmataha_pointcloud.laz: A dataset containing processed multibeam, single beam, and lidar data that have been merged into a single 3D point geometry dataset in compressed LASer file format, suitable for various applications in geographic information systems (GIS) and engineering. LakePushmataha_TIN.dxf: A Triangulated Irregular Network (TIN) generated in CloudCompare using the mesh creation tool, based on points classified as ground (code 2) and bathymetric point (code 40) from the topo-bathymetric dataset (LakePushmataha_PointCloud.laz). The point cloud was sub-sampled to a minimum spacing of 2 feet before meshing. Elevation values are stored in the "Z" coordinate of each TIN face vertex and are referenced to NAVD88 in feet. Horizontal vertex coordinates are referenced NAD83 (2011) and projected in feet to the Mississippi State Plane coordinate system. CUBE_uncertainty_270khz.tif: A raster file containing gridded uncertainty values at the 95% confidence interval, measured in feet, from a multibeam echo sounder (MBES) survey. Uncertainty was estimated through the Combined Uncertainty and Bathymetric Estimator (CUBE) method in HYPACK software, utilizing depth data collected at a frequency of 270 kHz, which showed the lowest bias relative to a merged bathymetric surface (see Attribute Accuracy for details). The raster has a grid size of 5 feet and is projected in the Mississippi East State Plane coordinate system. survey_extents.zip: A zipped directory containing an ESRI Shapefile of coverage polygons representing the approximate spatial extent of the respective survey method (single-beam, multibeam, or lidar). PhoenixUnmanned_lidar_processingreport.pdf: A processing report generated by Phoenix Unmanned, LLC that documents lidar performance, calibration, and accuracy tests.

The Junction class represents locations where lines connect to lines or lines connect to devices. A key use for junction features is to allow devices or lines to connect to another line at an intermediate vertex. You can think of a junction as 'glue point' at key places to connect all the features of a utility network. Junctions can be contained within assemblies.

The project leads for the collection of most of this data were Heiko Wittmer, Christopher Wilmers, Bogdan Cristescu, Pete Figura, David Casady, and Julie Garcia. Mule deer (82 adult females) from the Siskiyou herd were captured and equipped with GPS collars (Survey Globalstar, Vectronic Aerospace, Germany; Vertex Plus Iridium, Vectronic Aerospace, Germany), transmitting data from 2015-2020. The Siskiyou herd migrates from winter ranges primarily north and east of Mount Shasta (i.e., Shasta Valley, Red Rock Valley, Sheep Camp Butte, Sardine Flat, Long Prairie, and Little Hot Spring Valley) to sprawling summer ranges scattered between Mount Shasta in the west and the Burnt Lava Flow Geological Area to the east. A small percentage of the herd were residents. GPS locations were fixed between 1-2 hour intervals in the dataset. To improve the quality of the data set as per Bjørneraas et al. (2010), the GPS data were filtered prior to analysis to remove locations which were: i) further from either the previous point or subsequent point than an individual deer is able to travel in the elapsed time, ii) forming spikes in the movement trajectory based on outgoing and incoming speeds and turning angles sharper than a predefined threshold , or iii) fixed in 2D space and visually assessed as a bad fix by the analyst. The methodology used for this migration analysis allowed for the mapping of winter ranges and the identification and prioritization of migration corridors. Brownian Bridge Movement Models (BBMMs; Sawyer et al. 2009) were constructed with GPS collar data from 67 migrating deer, including 167 migration sequences, location, date, time, and average location error as inputs in Migration Mapper. The average migration time and average migration distance for deer was 12.09 days and 41.33 km, respectively. Corridors and stopovers were prioritized based on the number of animals moving through a particular area. BBMMs were produced at a spatial resolution of 50 m using a sequential fix interval of less than 27 hours. Due to often produced BBMM variance rates greater than 8000, separate models using BBMMs and fixed motion variances of 1000 were produced per migration sequence and visually compared for the entire dataset, with best models being combined prior to population-level analyses (62 percent of sequences selected with BMMM). Winter range analyses were based on data from 66 individual deer and 111 wintering sequences using a fixed motion variance of 1000. Winter range designations for this herd may expand with a larger sample, filling in some of the gaps between winter range polygons in the map. Large water bodies were clipped from the final outputs.Corridors are visualized based on deer use per cell, with greater than or equal to 1 deer, greater than or equal to 4 deer (10 percent of the sample), and greater than or equal to 7 deer (20 percent of the sample) representing migration corridors, medium use corridors, and high use corridors, respectively. Stopovers were calculated as the top 10 percent of the population level utilization distribution during migrations and can be interpreted as high use areas. Stopover polygon areas less than 20,000 m2 were removed, but remaining small stopovers may be interpreted as short-term resting sites, likely based on a small concentration of points from an individual animal. Winter range is visualized as the 50th percentile contour of the winter range utilization distribution.

The City Council of Madrid maintains the municipal topographic network as a uniform and precise framework for the coordination of all topographic work and cartographic products carried out in the area of the municipality. In 2020 it has been completely revised and densified to cover new urban developments. As of 2021 it is updated annually. The Topographic Network of Madrid (RTM) consists of more than 5,000 vertices materialized in the field. It is formed by vertices observed preferably by GPS and complementary to classical topography by precision polygonals. It includes the entire municipality of Madrid, except in Monte de El Pardo and Castillo de Viñuelas. It includes boundary markers of the municipal boundary, as well as vertices of other networks. It incorporates a subnet through all the tunnels of the city, so that it guarantees a single reference system both in surface and underground. It relies on the national geodetic infrastructure through the network of GNSS reference stations (ERGNSS) and the High Precision Leveling Network.

In June 2002, 200 1:20,000 scale conventional-color metric film diapositives for Long Island, New York were collected as part of an effort to map submerged aquatic vegetation (SAV) in Long Islands South Shore bays. They were provided by New York State Department of State's Division of Coastal Resources. Photographs were taken at low tide and during times that the growth stage of the SAV allowed for clear identification. Care was taken to minimize the effects of turbidity, sun glint, wind, and haze on the photos. The photos were scanned at a resolution of 15 microns. Ground control points were collected primarily from NYSDS 2 ft orthophotos. Additional control points were collected from USGS DOQQs where coverage from the primary source was lacking. All elevations were derived from USGS digital elevation models. A bundle block adjustment was performed using Albany and exterior orientation parameters were calculated. Boeing/Autometric's Softplotter was used to orthorectify the photos. The images were then dodged and mosaicked using Z/I's Orthopro. No additional color-balancing was performed as the mosaic's intended purpose was the delineation of benthic habitats. The mosaic was then output into 1000m by 1000m tiles with a 0.5m pixel resolution. The naming convention uses the first 3 numbers of the UTM x coordinate followed by the first 4 numbers in the UTM y coordinate of the southwest corner. Stereo digital images were created and the habitat features were interpreted and digitized on screen using softplotter microstation resulting in accurate and efficient 3D extraction of the data. Habitats were delineated with a high level of detail with the minimum mapping unit (MMU) being 0.01 hectares(approx.10m x 10m).The digitized polygons have the following specifications: Vertex Distance less than 1.0 m Node Snap Distance less than 4.0 m Arc Snap Distance less than 4.0 m During August 2002, NOAA staff collected 95 field observations throughout the study area and this information was incorporated into the map. In June 2003, after reviewing the photography, questionable areas were visited by Greenhorne and O'Mara staff and the findings were subsequently applied to the map. The map layers show delineated polygons and lines representing benthic habitat data. Each polygon feature is given a 1,2,3 or 4 digit number representing 11 habitats. The item numbers are stored in the attribute table under Text. The benthic data is classified according to the System for Classification of Habitats in Estuarine and Marine Environments (SCHEME). This system is fully described in "Development of a System for Classification of Habitats in Estuarine and Marine Environments (SCHEME) for Florida, Report to U.S. EPA - Gulf of Mexico Program, Florida Fish and Wildlife Conservation Commission, Florida Marine Research Institute. Review Draft 12/04/02."The collected data was converted to an ARCGIS format for quality control and delivery. The data was assessed for horizontal spatial accuracy and thematic agreement during 2003.View Dataset on the Gateway

Roads on the Dangermond Preserve. Attributes include road type, vehicle type needed for transportation, risk level, road surface composition, management zone and pasture through which road passes, conditions under which to flag road (e.g. rain), and tier. Closed roads are included in this layer.Provenance:The data originated as the 'Internal Roads' data provided to TNC during acquisition of the property. Dangermond base data received from WRA, Inc. - Environmental Consultants, September 19, 2017. Additional data supplemented by The Nature Conservancy, California Chapter, October 2017. After receiving these roads data TNC has completed the following 1) implemented a new data model, 2) transferred data from the former data model fields into the new data model fields as best we could, 3) added road names, using a 1998 scanned ranch map as reference, 4) added in Jalama Road and 5) edited the topology so that road segments start and end at vertices and every intersection is a vertex.Created from inf_roads and combined with jldp_roads_zones to have attributes for pastures, zones.Will replace all roads files and be used as primary road file going forward as of 02/2022. Road Segments are maintainedPlease note the Preserve is private property, no unauthorized access.

🇺🇸 미국 English The Watershed Boundary Dataset (WBD) is a seamless, national hydrologic unit dataset. Hydrologic units represent the area of the landscape that drains to a portion of the stream network. (https://www.usgs.gov/national-hydrography/watershed-boundary-dataset) It is maintained by the U.S. Geological Survey (USGS) in partnership with the states. The Department of Water Resources is the steward for the California portion of this dataset.The hydrologic units (HU) in the WBD form a standardized system for organizing, collecting, managing, and reporting hydrologic information for the nation. The HUs in the WBD are arranged in a nested, hierarchical system with each HU in the system identified using a unique code. Hydrologic unit codes (HUC) are developed using a progressive two-digit system where each successively smaller areal unit is identified by adding two digits to the identifying code the smaller unit is nested within. WBD contains eight levels of progressive hydrologic units identified by unique 2- to 16-digit codes. The dataset is complete for the United States to the 12-digit hydrologic unit. The 8-digit level unit is often referred to as HUC8 and is a commonly used reference framework for planning and environmental assessment. This particular version of the dataset was created by downloading the CA State extract of the National Hydrography Dataset from the USGS website https://www.usgs.gov/national-hydrography/access-national-hydrography-products and then performing a geoprocessing operation in ArcGIS Pro software to clip the HUC8s at the state of California political boundary. (https://data.cnra.ca.gov/dataset/california-county-boundaries2). A web map service was created with this dataset, but at it's original digitized resolution it can take a long time to render in a web map application. This dataset is a simplified version, created by use of the ArcGIS Simplify Polygon tool with the Douglas-Peucker Line simplification algorithm, reducing the vertex count from 1,095,449 to 9108. This dataset was reprojected from the original NAD 83 Geographic Coordinate System to WGS 1984 Web Mercator auxiliary sphere for use in web map applications. Any questions about this dataset may be sent to jane.schafer-kramer@water.ca.gov

Wetlands are areas where water is present at or near the surface of the soil during at least part of the year. Wetlands provide habitat for many species of plants and animals that are adapted to living in wet habitats. Wetlands form characteristic soils, absorb pollutants and excess nutrients from aquatic systems, help buffer the effects of high flows, and recharge groundwater. Data on the distribution and type of wetland play an important role in land use planning and several federal and state laws require that wetlands be considered during the planning process.The National Wetlands Inventory (NWI) was designed to assist land managers in wetland conservation efforts. The NWI is managed by the US Fish and Wildlife Service.Dataset SummaryPhenomenon Mapped: WetlandsCoordinate System: Web Mercator Auxiliary SphereExtent: 50 United States plus Puerto Rico, the US Virgin Islands and the Northern Mariana IslandsVisible Scale: The data is visible at scales from 1:144,000 to 1:1,000Resolution/Tolerance: 0.0001 meters/0.001 metersNumber of Features: 34,954,623 diced, after applying a 50,000 vertex limit to an original set of 34,950,653 featuresFeature Limit: 10,000Source: U.S. Fish and Wildlife ServicePublication Date: September 29, 2020ArcGIS Server URL: https://landscape11.arcgis.com/arcgis/This layer was created from the September 29, 2020 version of the NWI. This layer includes attributes from the original dataset as well as attributes added by Esri for use in the default pop-up and to allow the user to query and filter the data.NWI derived attributes:Wetland Code - a code that identifies specific attributes of the wetlandWetland Type - one of 8 wetland typesArea - area of the wetland in acresEsri created attributes:System - code indicating the system and subsystem of the wetlandClass - code indicating the class and subclass of the wetlandModifier 1, Modifier 2, Modifier 3, Modifier 4 - these four fields contain letter codes for modifiers applied to the wetland descriptionSystem Name - the name of the system (Marine, Estuarine, Riverine, Lacustrine, or Palustrine)Subsystem Name - the name of the subsystemClass Name - the name of the classSubclass Name - the name of the subclassModifier 1 Name, Modifier 2 Name, Modifier 3 Name , Modifier 4 Name - these four fields contain names for modifiers applied to the wetland descriptionPopup Header - this field contains a text string that is used to create the header in the default pop-up System Text - this field contains a text string that is used to create the system description text in the default pop-upClass Text - this field contains a text string that is used to create the class description text in the default pop-upModifier Text - this field contains a text string that is used to create the modifier description text in the default pop-upSpecies Text - this field contains a text string that is used to create the species description text in the default pop-upCodes, names, and text fields were derived from the publication Classification of Wetlands and Deepwater Habitats of the United States.What can you do with this Feature Layer?Feature layers work throughout the ArcGIS system. Generally your work flow with feature layers will begin in ArcGIS Online or ArcGIS Pro. Below are just a few of the things you can do with a feature service in Online and Pro.ArcGIS OnlineAdd this layer to a map in the map viewer. The layer is limited to scales of approximately 1:144,000 or larger but an imagery layer created from the same data can be used at smaller scales to produce a webmap that displays across the full scale range. The layer or a map containing it can be used in an application.Change the layer’s transparency and set its visibility rangeOpen the layer’s attribute table and make selections and apply filters. Selections made in the map or table are reflected in the other. Center on selection allows you to zoom to features selected in the map or table and show selected records allows you to view the selected records in the table.Change the layer’s style and filter the data. For example, you could set a filter for System Text = 'Palustrine' to create a map of palustrine wetlands only.Add labels and set their propertiesCustomize the pop-upArcGIS ProAdd this layer to a 2d or 3d map. The same scale limit as Online applies in ProUse as an input to geoprocessing. For example, copy features allows you to select then export portions of the data to a new feature class.Change the symbology and the attribute field used to symbolize the dataOpen table and make interactive selections with the mapModify the pop-upsApply Definition Queries to create sub-sets of the layerThis layer is part of the Living Atlas of the World that provides an easy way to explore the landscape layers and many other beautiful and authoritative maps on hundreds of topics.

This dataset represents road centerlines (RCLs) for all named streets (including those named with a number) and private driveways in Snohomish County for use in the Washington State Next Generation 911 (NG911) program to support emergency call routing. RCLs follow the NENA RCL GIS data model and are provided to the Washington State NG911 program on a monthly basis and to Snohomish County Public Safety Answering Points on request. Any other use of these data are not directly supported by Snohomish County.Roads and driveways are updated daily or weekly from addressing notifications sent from partner jurisdictions, Snohomish County PDS, SNO911 dispatcher comments, reports from field crews, UAS flights conducted by EESCS, and other verified data sources as required. Named roads are typically digitized from official site plans and occasionally deviate from final construction. Private driveways are added to support proper routing of emergency crews and often include unofficial or ad-hoc roadways, and will always join another RCL at a vertex. Named roads are split wherever they intersect another named road or cross a jurisdictional boundary. Fields include valid TO and FROM address ranges for the street segment. In some cases, RCLs in new developments may appear in data before the roadway is completed. For a detailed description of all fields please refer to the NENA NG911 data model: https://www.nena.org/page/ng911gisdatamodel

The Texas Department of Transportation (TxDOT) maintains a spatial dataset of roadway polylines for planning and asset inventory purposes, as well as for visualization and general mapping. This dataset covers the state of Texas and includes on-system routes (those that TxDOT maintains), such as interstate highways, U.S. highways, state highways, and farm and ranch roads, as well as off-system routes, such as county roads and local streets. Route segments in this version of TxDOT Roadways are broken by functional classification. For an unsegmented version of TxDOT Roadways, see TxDOT Roadways Unsegmented.This data contains measures. Measures are stored as M-values within each vertex along the line, in the same way that some datasets store z-values for the elevation, except that measures store the distance from the origin, or DFO, along the line. M-enabled networks serve as frameworks for locating roadway assets along the network using linear referencing. This data set must be downloaded as a file geodatabase in order to keep M-Values intact. If downloaded as a shapefile or added to a map from a connection to ArcGIS online, measures will not be applied to the line.Update Frequency: MonthlySource: Geospatial Roadway Inventory Database (GRID)Security Level: Public

This polygon was constructed from the GPS vertex positions using the NAD27 system and later re projected to WGS84. The original metadata reads: We are using the following GPS coordinates for the 480 m x 800 m rectangle (38.4-ha) encompassing the original 26.6-ha Gigante Fertilization Plot. The coordinates are based on the GPS location determined for position 210, 430 on the plot. Data were collected on 25 January 1998, using Pamela Philips’ rover while the base station at Tupper was simultaneously collecting data. Pamela Philips later differentially corrected the rover data against the base station data to provide us with this location. Easting and Northing are in UTMs. Pamela notes: UTM Zone 17, NAD 27.Since 210,430 is more-or-less near the centroid of the 38.4-ha rectangle, this will be used as the geo-referenced position of the Gigante Fertilization Project plot: 9 deg. 6 min. 30.71139 sec. N, 79 deg., 50 min., 36.89953 sec. W.