Description of columns in the ArcGIS point file "Points for Maps" which provides the final statistics used to make the maps of mean daily water levels and maps of the 25th, 50th, and 75th percentiles of daily water levels during 2000–2009 in Miami-Dade County; and maps showing the differences in the statistics of water levels between 1990–1999 and 2000–2009.
Statistical analyses and maps representing mean, high, and low water-level conditions in the surface water and groundwater of Miami-Dade County were made by the U.S. Geological Survey, in cooperation with the Miami-Dade County Department of Regulatory and Economic Resources, to help inform decisions necessary for urban planning and development. Sixteen maps were created that show contours of (1) the mean of daily water levels at each site during October and May for the 2000-2009 water years; (2) the 25th, 50th, and 75th percentiles of the daily water levels at each site during October and May and for all months during 2000-2009; and (3) the differences between mean October and May water levels, as well as the differences in the percentiles of water levels for all months, between 1990-1999 and 2000-2009. The 80th, 90th, and 96th percentiles of the annual maximums of daily groundwater levels during 1974-2009 (a 35-year period) were computed to provide an indication of unusually high groundwater-level conditions. These maps and statistics provide a generalized understanding of the variations of water levels in the aquifer, rather than a survey of concurrent water levels. Water-level measurements from 473 sites in Miami-Dade County and surrounding counties were analyzed to generate statistical analyses. The monitored water levels included surface-water levels in canals and wetland areas and groundwater levels in the Biscayne aquifer. Maps were created by importing site coordinates, summary water-level statistics, and completeness of record statistics into a geographic information system, and by interpolating between water levels at monitoring sites in the canals and water levels along the coastline. Raster surfaces were created from these data by using the triangular irregular network interpolation method. The raster surfaces were contoured by using geographic information system software. These contours were imprecise in some areas because the software could not fully evaluate the hydrology given available information; therefore, contours were manually modified where necessary. The ability to evaluate differences in water levels between 1990-1999 and 2000-2009 is limited in some areas because most of the monitoring sites did not have 80 percent complete records for one or both of these periods. The quality of the analyses was limited by (1) deficiencies in spatial coverage; (2) the combination of pre- and post-construction water levels in areas where canals, levees, retention basins, detention basins, or water-control structures were installed or removed; (3) an inability to address the potential effects of the vertical hydraulic head gradient on water levels in wells of different depths; and (4) an inability to correct for the differences between daily water-level statistics. Contours are dashed in areas where the locations of contours have been approximated because of the uncertainty caused by these limitations. Although the ability of the maps to depict differences in water levels between 1990-1999 and 2000-2009 was limited by missing data, results indicate that near the coast water levels were generally higher in May during 2000-2009 than during 1990-1999; and that inland water levels were generally lower during 2000-2009 than during 1990-1999. Generally, the 25th, 50th, and 75th percentiles of water levels from all months were also higher near the coast and lower inland during 2000–2009 than during 1990-1999. Mean October water levels during 2000-2009 were generally higher than during 1990-1999 in much of western Miami-Dade County, but were lower in a large part of eastern Miami-Dade County.
Attribution 4.0 (CC BY 4.0)https://creativecommons.org/licenses/by/4.0/
License information was derived automatically
The Address Points dataset shows Utah address points for all twenty-nine Utah counties. An address point represents a geographic location that has been assigned a US Postal Service (USPS) address by the local address authority (i.e., county or municipality) but does not necessarily receive mail. Address points may include several pieces of information about the structure or location that’s being mapped, such as:the full address (i.e., the USPS mailing address, if the address is for a physical location [rather than a PO box]);the landmark name; whether the location is a building;the type of unit;the city and ZIP code; unique code identifiers of the specific geographic location, including the Federal Information Processing Standard Publication (FIPS) county code and the US National Grid (USNG) spatial address;the address source; andthe date that the address point was loaded into the map layer.This dataset is mapping grade; it is a framework layer that receives regular updates. As with all our datasets, the Utah Geospatial Resource Center (UGRC) works to ensure the quality and accuracy of our data to the best of our abilities. Maintaining the dataset is now an ongoing effort between UGRC, counties, and municipalities. Specifically, UGRC works with each county or municipality’s Master Address List (MAL) authority to continually improve the address point data. Counties have been placed on an update schedule depending on the rate of new development and change within them. Populous counties, such as Weber, Davis, Salt Lake, Utah, and Washington, are more complete and are updated monthly, while rural or less populous counties may be updated quarterly or every six months.The information in the Address Points dataset was originally compiled by Utah counties and municipalities and was aggregated by UGRC for the MAL grant initiative in 2012. The purpose of this initiative was to make sure that all state entities were using the same verified, accurate county and municipal address information. Since 2012, more data has been added to the Address Points GIS data and is used for geocoding, 911 response, and analysis and planning purposes. The Address Point data is also used as reference data for the api.mapserv.utah.gov geocoding endpoint, and you can find the address points in many web mapping applications. This dataset is updated monthly and can also be found at: https://gis.utah.gov/data/location/address-data/.
Attribution 4.0 (CC BY 4.0)https://creativecommons.org/licenses/by/4.0/
License information was derived automatically
The Residential Schools Locations Dataset in Geodatabase format (IRS_Locations.gbd) contains a feature layer "IRS_Locations" that contains the locations (latitude and longitude) of Residential Schools and student hostels operated by the federal government in Canada. All the residential schools and hostels that are listed in the Residential Schools Settlement Agreement are included in this dataset, as well as several Industrial schools and residential schools that were not part of the IRRSA. This version of the dataset doesn’t include the five schools under the Newfoundland and Labrador Residential Schools Settlement Agreement. The original school location data was created by the Truth and Reconciliation Commission, and was provided to the researcher (Rosa Orlandini) by the National Centre for Truth and Reconciliation in April 2017. The dataset was created by Rosa Orlandini, and builds upon and enhances the previous work of the Truth and Reconcilation Commission, Morgan Hite (creator of the Atlas of Indian Residential Schools in Canada that was produced for the Tk'emlups First Nation and Justice for Day Scholar's Initiative, and Stephanie Pyne (project lead for the Residential Schools Interactive Map). Each individual school location in this dataset is attributed either to RSIM, Morgan Hite, NCTR or Rosa Orlandini. Many schools/hostels had several locations throughout the history of the institution. If the school/hostel moved from its’ original location to another property, then the school is considered to have two unique locations in this dataset,the original location and the new location. For example, Lejac Indian Residential School had two locations while it was operating, Stuart Lake and Fraser Lake. If a new school building was constructed on the same property as the original school building, it isn't considered to be a new location, as is the case of Girouard Indian Residential School.When the precise location is known, the coordinates of the main building are provided, and when the precise location of the building isn’t known, an approximate location is provided. For each residential school institution location, the following information is provided: official names, alternative name, dates of operation, religious affiliation, latitude and longitude coordinates, community location, Indigenous community name, contributor (of the location coordinates), school/institution photo (when available), location point precision, type of school (hostel or residential school) and list of references used to determine the location of the main buildings or sites. Access Instructions: there are 47 files in this data package. Please download the entire data package by selecting all the 47 files and click on download. Two files will be downloaded, IRS_Locations.gbd.zip and IRS_LocFields.csv. Uncompress the IRS_Locations.gbd.zip. Use QGIS, ArcGIS Pro, and ArcMap to open the feature layer IRS_Locations that is contained within the IRS_Locations.gbd data package. The feature layer is in WGS 1984 coordinate system. There is also detailed file level metadata included in this feature layer file. The IRS_locations.csv provides the full description of the fields and codes used in this dataset.
This dataset includes all 7 metro counties that have made their parcel data freely available without a license or fees.
This dataset is a compilation of tax parcel polygon and point layers assembled into a common coordinate system from Twin Cities, Minnesota metropolitan area counties. No attempt has been made to edgematch or rubbersheet between counties. A standard set of attribute fields is included for each county. The attributes are the same for the polygon and points layers. Not all attributes are populated for all counties.
NOTICE: The standard set of attributes changed to the MN Parcel Data Transfer Standard on 1/1/2019.
https://www.mngeo.state.mn.us/committee/standards/parcel_attrib/parcel_attrib.html
See section 5 of the metadata for an attribute summary.
Detailed information about the attributes can be found in the Metro Regional Parcel Attributes document.
The polygon layer contains one record for each real estate/tax parcel polygon within each county's parcel dataset. Some counties have polygons for each individual condominium, and others do not. (See Completeness in Section 2 of the metadata for more information.) The points layer includes the same attribute fields as the polygon dataset. The points are intended to provide information in situations where multiple tax parcels are represented by a single polygon. One primary example of this is the condominium, though some counties stacked polygons for condos. Condominiums, by definition, are legally owned as individual, taxed real estate units. Records for condominiums may not show up in the polygon dataset. The points for the point dataset often will be randomly placed or stacked within the parcel polygon with which they are associated.
The polygon layer is broken into individual county shape files. The points layer is provided as both individual county files and as one file for the entire metro area.
In many places a one-to-one relationship does not exist between these parcel polygons or points and the actual buildings or occupancy units that lie within them. There may be many buildings on one parcel and there may be many occupancy units (e.g. apartments, stores or offices) within each building. Additionally, no information exists within this dataset about residents of parcels. Parcel owner and taxpayer information exists for many, but not all counties.
This is a MetroGIS Regionally Endorsed dataset.
Additional information may be available from each county at the links listed below. Also, any questions or comments about suspected errors or omissions in this dataset can be addressed to the contact person at each individual county.
Anoka = http://www.anokacounty.us/315/GIS
Caver = http://www.co.carver.mn.us/GIS
Dakota = http://www.co.dakota.mn.us/homeproperty/propertymaps/pages/default.aspx
Hennepin = https://gis-hennepin.hub.arcgis.com/pages/open-data
Ramsey = https://www.ramseycounty.us/your-government/open-government/research-data
Scott = http://opendata.gis.co.scott.mn.us/
Washington: http://www.co.washington.mn.us/index.aspx?NID=1606
In 2007, the California Ocean Protection Council initiated the California Seafloor Mapping Program (CSMP), designed to create a comprehensive seafloor map of high-resolution bathymetry, marine benthic habitats, and geology within California’s State Waters. The program supports a large number of coastal-zone- and ocean-management issues, including the California Marine Life Protection Act (MLPA) (California Department of Fish and Wildlife, 2008), which requires information about the distribution of ecosystems as part of the design and proposal process for the establishment of Marine Protected Areas. A focus of CSMP is to map California’s State Waters with consistent methods at a consistent scale. The CSMP approach is to create highly detailed seafloor maps through collection, integration, interpretation, and visualization of swath sonar data (the undersea equivalent of satellite remote-sensing data in terrestrial mapping), acoustic backscatter, seafloor video, seafloor photography, high-resolution seismic-reflection profiles, and bottom-sediment sampling data. The map products display seafloor morphology and character, identify potential marine benthic habitats, and illustrate both the surficial seafloor geology and shallow (to about 100 m) subsurface geology. It is emphasized that the more interpretive habitat and geology data rely on the integration of multiple, new high-resolution datasets and that mapping at small scales would not be possible without such data. This approach and CSMP planning is based in part on recommendations of the Marine Mapping Planning Workshop (Kvitek and others, 2006), attended by coastal and marine managers and scientists from around the state. That workshop established geographic priorities for a coastal mapping project and identified the need for coverage of “lands” from the shore strand line (defined as Mean Higher High Water; MHHW) out to the 3-nautical-mile (5.6-km) limit of California’s State Waters. Unfortunately, surveying the zone from MHHW out to 10-m water depth is not consistently possible using ship-based surveying methods, owing to sea state (for example, waves, wind, or currents), kelp coverage, and shallow rock outcrops. Accordingly, some of the data presented in this series commonly do not cover the zone from the shore out to 10-m depth. This data is part of a series of online U.S. Geological Survey (USGS) publications, each of which includes several map sheets, some explanatory text, and a descriptive pamphlet. Each map sheet is published as a PDF file. Geographic information system (GIS) files that contain both ESRI ArcGIS raster grids (for example, bathymetry, seafloor character) and geotiffs (for example, shaded relief) are also included for each publication. For those who do not own the full suite of ESRI GIS and mapping software, the data can be read using ESRI ArcReader, a free viewer that is available at http://www.esri.com/software/arcgis/arcreader/index.html (last accessed September 20, 2013). The California Seafloor Mapping Program is a collaborative venture between numerous different federal and state agencies, academia, and the private sector. CSMP partners include the California Coastal Conservancy, the California Ocean Protection Council, the California Department of Fish and Wildlife, the California Geological Survey, California State University at Monterey Bay’s Seafloor Mapping Lab, Moss Landing Marine Laboratories Center for Habitat Studies, Fugro Pelagos, Pacific Gas and Electric Company, National Oceanic and Atmospheric Administration (NOAA, including National Ocean Service–Office of Coast Surveys, National Marine Sanctuaries, and National Marine Fisheries Service), U.S. Army Corps of Engineers, the Bureau of Ocean Energy Management, the National Park Service, and the U.S. Geological Survey. These web services for the Offshore of Coal Oil Point map area includes data layers that are associated to GIS and map sheets available from the USGS CSMP web page at https://walrus.wr.usgs.gov/mapping/csmp/index.html. Each published CSMP map area includes a data catalog of geographic information system (GIS) files; map sheets that contain explanatory text; and an associated descriptive pamphlet. This web service represents the available data layers for this map area. Data was combined from different sonar surveys to generate a comprehensive high-resolution bathymetry and acoustic-backscatter coverage of the map area. These data reveal a range of physiographic including exposed bedrock outcrops, large fields of sand waves, as well as many human impacts on the seafloor. To validate geological and biological interpretations of the sonar data, the U.S. Geological Survey towed a camera sled over specific offshore locations, collecting both video and photographic imagery; these “ground-truth” surveying data are available from the CSMP Video and Photograph Portal at https://doi.org/10.5066/F7J1015K. The “seafloor character” data layer shows classifications of the seafloor on the basis of depth, slope, rugosity (ruggedness), and backscatter intensity and which is further informed by the ground-truth-survey imagery. The “potential habitats” polygons are delineated on the basis of substrate type, geomorphology, seafloor process, or other attributes that may provide a habitat for a specific species or assemblage of organisms. Representative seismic-reflection profile data from the map area is also include and provides information on the subsurface stratigraphy and structure of the map area. The distribution and thickness of young sediment (deposited over the past about 21,000 years, during the most recent sea-level rise) is interpreted on the basis of the seismic-reflection data. The geologic polygons merge onshore geologic mapping (compiled from existing maps by the California Geological Survey) and new offshore geologic mapping that is based on integration of high-resolution bathymetry and backscatter imagery seafloor-sediment and rock samplesdigital camera and video imagery, and high-resolution seismic-reflection profiles. The information provided by the map sheets, pamphlet, and data catalog has a broad range of applications. High-resolution bathymetry, acoustic backscatter, ground-truth-surveying imagery, and habitat mapping all contribute to habitat characterization and ecosystem-based management by providing essential data for delineation of marine protected areas and ecosystem restoration. Many of the maps provide high-resolution baselines that will be critical for monitoring environmental change associated with climate change, coastal development, or other forcings. High-resolution bathymetry is a critical component for modeling coastal flooding caused by storms and tsunamis, as well as inundation associated with longer term sea-level rise. Seismic-reflection and bathymetric data help characterize earthquake and tsunami sources, critical for natural-hazard assessments of coastal zones. Information on sediment distribution and thickness is essential to the understanding of local and regional sediment transport, as well as the development of regional sediment-management plans. In addition, siting of any new offshore infrastructure (for example, pipelines, cables, or renewable-energy facilities) will depend on high-resolution mapping. Finally, this mapping will both stimulate and enable new scientific research and also raise public awareness of, and education about, coastal environments and issues. Web services were created using an ArcGIS service definition file. The ArcGIS REST service and OGC WMS service include all Offshore Coal Oil Point map area data layers. Data layers are symbolized as shown on the associated map sheets.
This dataset contains address points that have been generated at the centroid of a property or on a building footprint. The property layer and the Regional road network were used in conjunction with the Region's address repository to generate the data. The Assessment Roll Number (ARN) of the parcel associated with each address has been included in the attribute table . The address repository is based upon various sources, with additional addresses and updates completed by the Region of Niagara GIS Services staff.
These points now include all the new addresses as a result of the Wainfleet Readdressing project. Old Wainfleet alpha-numeric addresses have been retired.The dataset extent corresponds to the Region of Niagara.
Link to the ScienceBase Item Summary page for the item described by this metadata record. Service Protocol: Link to the ScienceBase Item Summary page for the item described by this metadata record. Application Profile: Web Browser. Link Function: information
https://spdx.org/licenses/CC0-1.0.htmlhttps://spdx.org/licenses/CC0-1.0.html
A major objective of plant ecology research is to determine the underlying processes responsible for the observed spatial distribution patterns of plant species. Plants can be approximated as points in space for this purpose, and thus, spatial point pattern analysis has become increasingly popular in ecological research. The basic piece of data for point pattern analysis is a point location of an ecological object in some study region. Therefore, point pattern analysis can only be performed if data can be collected. However, due to the lack of a convenient sampling method, a few previous studies have used point pattern analysis to examine the spatial patterns of grassland species. This is unfortunate because being able to explore point patterns in grassland systems has widespread implications for population dynamics, community-level patterns and ecological processes. In this study, we develop a new method to measure individual coordinates of species in grassland communities. This method records plant growing positions via digital picture samples that have been sub-blocked within a geographical information system (GIS). Here, we tested out the new method by measuring the individual coordinates of Stipa grandis in grazed and ungrazed S. grandis communities in a temperate steppe ecosystem in China. Furthermore, we analyzed the pattern of S. grandis by using the pair correlation function g(r) with both a homogeneous Poisson process and a heterogeneous Poisson process. Our results showed that individuals of S. grandis were overdispersed according to the homogeneous Poisson process at 0-0.16 m in the ungrazed community, while they were clustered at 0.19 m according to the homogeneous and heterogeneous Poisson processes in the grazed community. These results suggest that competitive interactions dominated the ungrazed community, while facilitative interactions dominated the grazed community. In sum, we successfully executed a new sampling method, using digital photography and a Geographical Information System, to collect experimental data on the spatial point patterns for the populations in this grassland community.
Methods 1. Data collection using digital photographs and GIS
A flat 5 m x 5 m sampling block was chosen in a study grassland community and divided with bamboo chopsticks into 100 sub-blocks of 50 cm x 50 cm (Fig. 1). A digital camera was then mounted to a telescoping stake and positioned in the center of each sub-block to photograph vegetation within a 0.25 m2 area. Pictures were taken 1.75 m above the ground at an approximate downward angle of 90° (Fig. 2). Automatic camera settings were used for focus, lighting and shutter speed. After photographing the plot as a whole, photographs were taken of each individual plant in each sub-block. In order to identify each individual plant from the digital images, each plant was uniquely marked before the pictures were taken (Fig. 2 B).
Digital images were imported into a computer as JPEG files, and the position of each plant in the pictures was determined using GIS. This involved four steps: 1) A reference frame (Fig. 3) was established using R2V software to designate control points, or the four vertexes of each sub-block (Appendix S1), so that all plants in each sub-block were within the same reference frame. The parallax and optical distortion in the raster images was then geometrically corrected based on these selected control points; 2) Maps, or layers in GIS terminology, were set up for each species as PROJECT files (Appendix S2), and all individuals in each sub-block were digitized using R2V software (Appendix S3). For accuracy, the digitization of plant individual locations was performed manually; 3) Each plant species layer was exported from a PROJECT file to a SHAPE file in R2V software (Appendix S4); 4) Finally each species layer was opened in Arc GIS software in the SHAPE file format, and attribute data from each species layer was exported into Arc GIS to obtain the precise coordinates for each species. This last phase involved four steps of its own, from adding the data (Appendix S5), to opening the attribute table (Appendix S6), to adding new x and y coordinate fields (Appendix S7) and to obtaining the x and y coordinates and filling in the new fields (Appendix S8).
To determine the accuracy of our new method, we measured the individual locations of Leymus chinensis, a perennial rhizome grass, in representative community blocks 5 m x 5 m in size in typical steppe habitat in the Inner Mongolia Autonomous Region of China in July 2010 (Fig. 4 A). As our standard for comparison, we used a ruler to measure the individual coordinates of L. chinensis. We tested for significant differences between (1) the coordinates of L. chinensis, as measured with our new method and with the ruler, and (2) the pair correlation function g of L. chinensis, as measured with our new method and with the ruler (see section 3.2 Data Analysis). If (1) the coordinates of L. chinensis, as measured with our new method and with the ruler, and (2) the pair correlation function g of L. chinensis, as measured with our new method and with the ruler, did not differ significantly, then we could conclude that our new method of measuring the coordinates of L. chinensis was reliable.
We compared the results using a t-test (Table 1). We found no significant differences in either (1) the coordinates of L. chinensis or (2) the pair correlation function g of L. chinensis. Further, we compared the pattern characteristics of L. chinensis when measured by our new method against the ruler measurements using a null model. We found that the two pattern characteristics of L. chinensis did not differ significantly based on the homogenous Poisson process or complete spatial randomness (Fig. 4 B). Thus, we concluded that the data obtained using our new method was reliable enough to perform point pattern analysis with a null model in grassland communities.
Statewide 2016 Lidar points colorized with 2018 NAIP imagery as a scene created by Esri using ArcGIS Pro for the entire State of Connecticut. This service provides the colorized Lidar point in interactive 3D for visualization, interaction of the ability to make measurements without downloading.Lidar is referenced at https://cteco.uconn.edu/data/lidar/ and can be downloaded at https://cteco.uconn.edu/data/download/flight2016/. Metadata: https://cteco.uconn.edu/data/flight2016/info.htm#metadata. The Connecticut 2016 Lidar was captured between March 11, 2016 and April 16, 2016. Is covers 5,240 sq miles and is divided into 23, 381 tiles. It was acquired by the Captiol Region Council of Governments with funding from multiple state agencies. It was flown and processed by Sanborn. The delivery included classified point clouds and 1 meter QL2 DEMs. The 2016 Lidar is published on the Connecticut Environmental Conditions Online (CT ECO) website. CT ECO is the collaborative work of the Connecticut Department of Energy and Environmental Protection (DEEP) and the University of Connecticut Center for Land Use Education and Research (CLEAR) to share environmental and natural resource information with the general public. CT ECO's mission is to encourage, support, and promote informed land use and development decisions in Connecticut by providing local, state and federal agencies, and the public with convenient access to the most up-to-date and complete natural resource information available statewide.Process used:Extract Building Footprints from Lidar1. Prepare Lidar - Download 2016 Lidar from CT ECO- Create LAS Dataset2. Extract Building Footprints from LidarUse the LAS Dataset in the Classify Las Building Tool in ArcGIS Pro 2.4.Colorize LidarColorizing the Lidar points means that each point in the point cloud is given a color based on the imagery color value at that exact location.1. Prepare Imagery- Acquire 2018 NAIP tif tiles from UConn (originally from USDA NRCS).- Create mosaic dataset of the NAIP imagery.2. Prepare and Analyze Lidar Points- Change the coordinate system of each of the lidar tiles to the Projected Coordinate System CT NAD 83 (2011) Feet (EPSG 6434). This is because the downloaded tiles come in to ArcGIS as a Custom Projection which cannot be published as a Point Cloud Scene Layer Package.- Convert Lidar to zlas format and rearrange. - Create LAS Datasets of the lidar tiles.- Colorize Lidar using the Colorize LAS tool in ArcGIS Pro. - Create a new LAS dataset with a division of Eastern half and Western half due to size limitation of 500GB per scene layer package. - Create scene layer packages (.slpk) using Create Cloud Point Scene Layer Package. - Load package to ArcGIS Online using Share Package. - Publish on ArcGIS.com and delete the scene layer package to save storage cost.Additional layers added:Visit https://cteco.uconn.edu/projects/lidar3D/layers.htm for a complete list and links. 3D Buildings and Trees extracted by Esri from the lidarShaded Relief from CTECOImpervious Surface 2012 from CT ECONAIP Imagery 2018 from CTECOContours (2016) from CTECOLidar 2016 Download Link derived from https://www.cteco.uconn.edu/data/download/flight2016/index.htm
This layer is utilized in Next Generation 911 for both geospatial call routing and location validation functions. Creation and maintenance of data is performed by local Public Safety Answering Points in partnership with counties, GIS vendors, and other public safety agencies and with support from the Nebraska Public Service Commission. Disparate datasets are aggregated at the state level and provisioned to the NG911 core services by the 911 department of the PSC. The component datasets have been standardized sufficiently to serve the purposes of NG911 core services, but differences in methodology may persist depending on the use cases for local jurisdictions; for example, some counties may develop points to represent the points of actual structures, while others may develop points representing access points to properties. Similarly, some jurisdictions may have sub-address points for locations with multiple structures or units sharing an address, while others may only have a single point to represent such locations.
The classification of point cloud datasets to identify distribution wires is useful for identifying vegetation encroachment around power lines. Such workflows are important for preventing fires and power outages and are typically manual, recurring, and labor-intensive. This model is designed to extract distribution wires at the street level. Its predictions for high-tension transmission wires are less consistent with changes in geography as compared to street-level distribution wires. In the case of high-tension transmission wires, a lower ‘recall’ value is observed as compared to the value observed for low-lying street wires and poles.Using the modelFollow the guide to use the model. The model can be used with ArcGIS Pro's Classify Point Cloud Using Trained Model tool. Before using this model, ensure that the supported deep learning libraries are installed. For more details, check Deep Learning Libraries Installer for ArcGIS.InputThe model accepts unclassified point clouds with point geometry (X, Y and Z values). Note: The model is not dependent on any additional attributes such as Intensity, Number of Returns, etc. This model is trained to work on unclassified point clouds that are in a projected coordinate system, in which the units of X, Y and Z are based on the metric system of measurement. If the dataset is in degrees or feet, it needs to be re-projected accordingly. The model was trained using a training dataset with the full set of points. Therefore, it is important to make the full set of points available to the neural network while predicting - allowing it to better discriminate points of 'class of interest' versus background points. It is recommended to use 'selective/target classification' and 'class preservation' functionalities during prediction to have better control over the classification and scenarios with false positives.The model was trained on airborne lidar datasets and is expected to perform best with similar datasets. Classification of terrestrial point cloud datasets may work but has not been validated. For such cases, this pre-trained model may be fine-tuned to save on cost, time, and compute resources while improving accuracy. Another example where fine-tuning this model can be useful is when the object of interest is tram wires, railway wires, etc. which are geometrically similar to electricity wires. When fine-tuning this model, the target training data characteristics such as class structure, maximum number of points per block and extra attributes should match those of the data originally used for training this model (see Training data section below).OutputThe model will classify the point cloud into the following classes with their meaning as defined by the American Society for Photogrammetry and Remote Sensing (ASPRS) described below: Classcode Class Description 0 Background Class 14 Distribution Wires 15 Distribution Tower/PolesApplicable geographiesThe model is expected to work within any geography. It's seen to produce favorable results as shown here in many regions. However, results can vary for datasets that are statistically dissimilar to training data.Model architectureThis model uses the RandLANet model architecture implemented in ArcGIS API for Python.Accuracy metricsThe table below summarizes the accuracy of the predictions on the validation dataset. - Precision Recall F1-score Background (0) 0.999679 0.999876 0.999778 Distribution Wires (14) 0.955085 0.936825 0.945867 Distribution Poles (15) 0.707983 0.553888 0.621527Training dataThis model is trained on manually classified training dataset provided to Esri by AAM group. The training data used has the following characteristics: X, Y, and Z linear unitmeter Z range-240.34 m to 731.17 m Number of Returns1 to 5 Intensity1 to 4095 Point spacing0.2 ± 0.1 Scan angle-42 to +35 Maximum points per block20000 Extra attributesNone Class structure[0, 14, 15]Sample resultsHere are a few results from the model.
social system, socio-economic resources, justice, BES, Environmental disamentities, Environmental Justice, Zoning Board of Appeals
Summary
For use in the environmental injustices study of Baltimore relating to patterns of environmental disamenties in relation to low income/minority communities.
Description
This feature class layer is a point dataset of authorizing ordinances from the Baltimore City Council and Mayor from 1930 until 1999 concerning identified environmental disamentities. The data was gathered from records from the City Council since 1930 relating to decisions concerning land-uses considered to be environmental disamentities and is to be used to examine environmental injustices involving low income/minority communities in Baltimore. To examine if environmental injustices exist in Baltimore, this point layer will be overlayed with race/income data to determine if patterns of inequity exist. Points were placed manually using the associated addresses from the Ordinance_master dataset and using ISTAR 2004 data in conjunction with Baltimore parcel data. The Ordinance_ID number associated with each point relates to its appeal number from the City Council. Multiple points on the data layer have the same Ordinance_ID. This point layer can be joined with the Ordinance_master data layer based on the field "Ordinance_ID" and using the relationship "Ordinance_point_relationship".
Credits
UVM Spatial Analysis Lab
Use limitations
None. There are no restrictions on the use of this dataset. The authors of this dataset make no representations of any kind, including but not limited to the warranties of merchantability or fitness for a particular use, nor are any such warranties to be implied with respect to the data.
Extent
West -76.707701 East -76.526991
North 39.371885 South 39.200794
This is part of a collection of 221 Baltimore Ecosystem Study metadata records that point to a geodatabase.
The geodatabase is available online and is considerably large. Upon request, and under certain arrangements, it can be shipped on media, such as a usb hard drive.
The geodatabase is roughly 51.4 Gb in size, consisting of 4,914 files in 160 folders.
Although this metadata record and the others like it are not rich with attributes, it is nonetheless made available because the data that it represents could be indeed useful.
This is part of a collection of 221 Baltimore Ecosystem Study metadata records that point to a geodatabase.
The geodatabase is available online and is considerably large. Upon request, and under certain arrangements, it can be shipped on media, such as a usb hard drive.
The geodatabase is roughly 51.4 Gb in size, consisting of 4,914 files in 160 folders.
Although this metadata record and the others like it are not rich with attributes, it is nonetheless made available because the data that it represents could be indeed useful.
Attribution 4.0 (CC BY 4.0)https://creativecommons.org/licenses/by/4.0/
License information was derived automatically
The Address Points dataset shows Utah address points for all twenty-nine Utah counties. An address point represents a geographic location that has been assigned a US Postal Service (USPS) address by the local address authority (i.e., county or municipality) but does not necessarily receive mail. Address points may include several pieces of information about the structure or location that’s being mapped, such as:the full address (i.e., the USPS mailing address, if the address is for a physical location [rather than a PO box]);the landmark name; whether the location is a building;the type of unit;the city and ZIP code; unique code identifiers of the specific geographic location, including the Federal Information Processing Standard Publication (FIPS) county code and the US National Grid (USNG) spatial address;the address source; andthe date that the address point was loaded into the map layer.This dataset is mapping grade; it is a framework layer that receives regular updates. As with all our datasets, the Utah Geospatial Resource Center (UGRC) works to ensure the quality and accuracy of our data to the best of our abilities. Maintaining the dataset is now an ongoing effort between UGRC, counties, and municipalities. Specifically, UGRC works with each county or municipality’s Master Address List (MAL) authority to continually improve the address point data. Counties have been placed on an update schedule depending on the rate of new development and change within them. Populous counties, such as Weber, Davis, Salt Lake, Utah, and Washington, are more complete and are updated monthly, while rural or less populous counties may be updated quarterly or every six months.The information in the Address Points dataset was originally compiled by Utah counties and municipalities and was aggregated by UGRC for the MAL grant initiative in 2012. The purpose of this initiative was to make sure that all state entities were using the same verified, accurate county and municipal address information. Since 2012, more data has been added to the Address Points GIS data and is used for geocoding, 911 response, and analysis and planning purposes. The Address Point data is also used as reference data for the api.mapserv.utah.gov geocoding endpoint, and you can find the address points in many web mapping applications. This dataset is updated monthly and can also be found at: https://gis.utah.gov/data/location/address-data/.
Attribution 4.0 (CC BY 4.0)https://creativecommons.org/licenses/by/4.0/
License information was derived automatically
MCGD_Data_V2.2 contains all the data that we have collected on locations in modern China, plus a number of locations outside of China that we encounter frequently in historical sources on China. All further updates will appear under the name "MCGD_Data" with a time stamp (e.g., MCGD_Data2023-06-21)
You can also have access to this dataset and all the datasets that the ENP-China makes available on GitLab: https://gitlab.com/enpchina/IndexesEnp
Altogether there are 464,970 entries. The data include the name of locations and their variants in Chinese, pinyin, and any recorded transliteration; the name of the province in Chinese and in pinyin; Province ID; the latitude and longitude; the Name ID and Location ID, and NameID_Legacy. The Name IDs all start with H followed by seven digits. This is the internal ID system of MCGD (the NameID_Legacy column records the Name IDs in their original format depending on the source). Locations IDs that start with "DH" are data points extracted from China Historical GIS (Harvard University); those that start with "D" are locations extracted from the data points in Geonames; those that have only digits (8 digits) are data points we have added from various map sources.
One of the main features of the MCGD Main Dataset is the systematic collection and compilation of place names from non-Chinese language historical sources. Locations were designated in transliteration systems that are hardly comprehensible today, which makes it very difficult to find the actual locations they correspond to. This dataset allows for the conversion from these obsolete transliterations to the current names and geocoordinates.
From June 2021 onward, we have adopted a different file naming system to keep track of versions. From MCGD_Data_V1 we have moved to MCGD_Data_V2. In June 2022, we introduced time stamps, which result in the following naming convention: MCGD_Data_YYYY.MM.DD.
UPDATES
MCGD_Data2025_02_28 includes a major change with the duplication of all the locations listed under Beijing, Shanghai, Tianjin, and Chongqing (北京, 上海, 天津, 重慶) and their listing under the name of the provinces to which they belonge origially before the creation of the four special municipalities after 1949. This is meant to facilitate the matching of data from historical sources. Each location has a unique NameID. Altogether there are 472,818 entries
MCGD_Data2025_02_27 inclues an update on locations extracted from Minguo zhengfu ge yuanhui keyuan yishang zhiyuanlu 國民政府各院部會科員以上職員錄 (Directory of staff members and above in the ministries and committees of the National Government). Nanjing: Guomin zhengfu wenguanchu yinzhuju 國民政府文官處印鑄局國民政府文官處印鑄局, 1944). We also made corrections in the Prov_Py and Prov_Zh columns as there were some misalignments between the pinyin name and the name in Chines characters. The file now includes 465,128 entries.
MCGD_Data2024_03_23 includes an update on locations in Taiwan from the Asia Directories. Altogether there are 465,603 entries (of which 187 place names without geocoordinates, labelled in the Lat Long columns as "Unknown").
MCGD_Data2023.12.22 contains all the data that we have collected on locations in China, whatever the period. Altogether there are 465,603 entries (of which 187 place names without geocoordinates, labelled in the Lat Long columns as "Unknown"). The dataset also includes locations outside of China for the purpose of matching such locations to the place names extracted from historical sources. For example, one may need to locate individuals born outside of China. Rather than maintaining two separate files, we made the decision to incorporate all the place names found in historical sources in the gazetteer. Such place names can easily be removed by selecting all the entries where the 'Province' data is missing.
This dataset represents the address point locations assigned by the Mat-Su Borough GIS/Addressing staff. Most of the parcels within the Mat-Su Borough that are road accessible have been assigned a physical address except where the access point is unknown, as with undeveloped corner lots. The address points in this dataset do not necessarily represent precise building locations as the data was originally based on the underlying parcel centroids. Data has historically been constructed and maintained using ArcView and ArcEditor applications. The current address assignment process involves using an ArcMap extension called MapSAG, which creates point features as directed by the GIS Addressing staff. Address information is populated at this time. As underlying parcel data accuracy has been spatially improved through field verification and mapping grade GPS equipment, address points have been shifted accordingly to fall within the appropriate parcels.
MIT Licensehttps://opensource.org/licenses/MIT
License information was derived automatically
WARNING: This is a pre-release dataset and its fields names and data structures are subject to change. It should be considered pre-release until the end of 2024. Expected changes:Metadata is missing or incomplete for some layers at this time and will be continuously improved.We expect to update this layer roughly in line with CDTFA at some point, but will increase the update cadence over time as we are able to automate the final pieces of the process.This dataset is continuously updated as the source data from CDTFA is updated, as often as many times a month. If you require unchanging point-in-time data, export a copy for your own use rather than using the service directly in your applications.PurposeCounty and incorporated place (city) boundaries along with third party identifiers used to join in external data. Boundaries are from the authoritative source the California Department of Tax and Fee Administration (CDTFA), altered to show the counties as one polygon. This layer displays the city polygons on top of the County polygons so the area isn"t interrupted. The GEOID attribute information is added from the US Census. GEOID is based on merged State and County FIPS codes for the Counties. Abbreviations for Counties and Cities were added from Caltrans Division of Local Assistance (DLA) data. Place Type was populated with information extracted from the Census. Names and IDs from the US Board on Geographic Names (BGN), the authoritative source of place names as published in the Geographic Name Information System (GNIS), are attached as well. Finally, coastal buffers are removed, leaving the land-based portions of jurisdictions. This feature layer is for public use.Related LayersThis dataset is part of a grouping of many datasets:Cities: Only the city boundaries and attributes, without any unincorporated areasWith Coastal BuffersWithout Coastal BuffersCounties: Full county boundaries and attributes, including all cities within as a single polygonWith Coastal BuffersWithout Coastal BuffersCities and Full Counties: A merge of the other two layers, so polygons overlap within city boundaries. Some customers require this behavior, so we provide it as a separate service.With Coastal BuffersWithout Coastal Buffers (this dataset)Place AbbreviationsUnincorporated Areas (Coming Soon)Census Designated Places (Coming Soon)Cartographic CoastlinePolygonLine source (Coming Soon)Working with Coastal BuffersThe dataset you are currently viewing includes the coastal buffers for cities and counties that have them in the authoritative source data from CDTFA. In the versions where they are included, they remain as a second polygon on cities or counties that have them, with all the same identifiers, and a value in the COASTAL field indicating if it"s an ocean or a bay buffer. If you wish to have a single polygon per jurisdiction that includes the coastal buffers, you can run a Dissolve on the version that has the coastal buffers on all the fields except COASTAL, Area_SqMi, Shape_Area, and Shape_Length to get a version with the correct identifiers.Point of ContactCalifornia Department of Technology, Office of Digital Services, odsdataservices@state.ca.govField and Abbreviation DefinitionsCOPRI: county number followed by the 3-digit city primary number used in the Board of Equalization"s 6-digit tax rate area numbering systemPlace Name: CDTFA incorporated (city) or county nameCounty: CDTFA county name. For counties, this will be the name of the polygon itself. For cities, it is the name of the county the city polygon is within.Legal Place Name: Board on Geographic Names authorized nomenclature for area names published in the Geographic Name Information SystemGNIS_ID: The numeric identifier from the Board on Geographic Names that can be used to join these boundaries to other datasets utilizing this identifier.GEOID: numeric geographic identifiers from the US Census Bureau Place Type: Board on Geographic Names authorized nomenclature for boundary type published in the Geographic Name Information SystemPlace Abbr: CalTrans Division of Local Assistance abbreviations of incorporated area namesCNTY Abbr: CalTrans Division of Local Assistance abbreviations of county namesArea_SqMi: The area of the administrative unit (city or county) in square miles, calculated in EPSG 3310 California Teale Albers.COASTAL: Indicates if the polygon is a coastal buffer. Null for land polygons. Additional values include "ocean" and "bay".GlobalID: While all of the layers we provide in this dataset include a GlobalID field with unique values, we do not recommend you make any use of it. The GlobalID field exists to support offline sync, but is not persistent, so data keyed to it will be orphaned at our next update. Use one of the other persistent identifiers, such as GNIS_ID or GEOID instead.AccuracyCDTFA"s source data notes the following about accuracy:City boundary changes and county boundary line adjustments filed with the Board of Equalization per Government Code 54900. This GIS layer contains the boundaries of the unincorporated county and incorporated cities within the state of California. The initial dataset was created in March of 2015 and was based on the State Board of Equalization tax rate area boundaries. As of April 1, 2024, the maintenance of this dataset is provided by the California Department of Tax and Fee Administration for the purpose of determining sales and use tax rates. The boundaries are continuously being revised to align with aerial imagery when areas of conflict are discovered between the original boundary provided by the California State Board of Equalization and the boundary made publicly available by local, state, and federal government. Some differences may occur between actual recorded boundaries and the boundaries used for sales and use tax purposes. The boundaries in this map are representations of taxing jurisdictions for the purpose of determining sales and use tax rates and should not be used to determine precise city or county boundary line locations. COUNTY = county name; CITY = city name or unincorporated territory; COPRI = county number followed by the 3-digit city primary number used in the California State Board of Equalization"s 6-digit tax rate area numbering system (for the purpose of this map, unincorporated areas are assigned 000 to indicate that the area is not within a city).Boundary ProcessingThese data make a structural change from the source data. While the full boundaries provided by CDTFA include coastal buffers of varying sizes, many users need boundaries to end at the shoreline of the ocean or a bay. As a result, after examining existing city and county boundary layers, these datasets provide a coastline cut generally along the ocean facing coastline. For county boundaries in northern California, the cut runs near the Golden Gate Bridge, while for cities, we cut along the bay shoreline and into the edge of the Delta at the boundaries of Solano, Contra Costa, and Sacramento counties.In the services linked above, the versions that include the coastal buffers contain them as a second (or third) polygon for the city or county, with the value in the COASTAL field set to whether it"s a bay or ocean polygon. These can be processed back into a single polygon by dissolving on all the fields you wish to keep, since the attributes, other than the COASTAL field and geometry attributes (like areas) remain the same between the polygons for this purpose.SliversIn cases where a city or county"s boundary ends near a coastline, our coastline data may cross back and forth many times while roughly paralleling the jurisdiction"s boundary, resulting in many polygon slivers. We post-process the data to remove these slivers using a city/county boundary priority algorithm. That is, when the data run parallel to each other, we discard the coastline cut and keep the CDTFA-provided boundary, even if it extends into the ocean a small amount. This processing supports consistent boundaries for Fort Bragg, Point Arena, San Francisco, Pacifica, Half Moon Bay, and Capitola, in addition to others. More information on this algorithm will be provided soon.Coastline CaveatsSome cities have buffers extending into water bodies that we do not cut at the shoreline. These include South Lake Tahoe and Folsom, which extend into neighboring lakes, and San Diego and surrounding cities that extend into San Diego Bay, which our shoreline encloses. If you have feedback on the exclusion of these items, or others, from the shoreline cuts, please reach out using the contact information above.Offline UseThis service is fully enabled for sync and export using Esri Field Maps or other similar tools. Importantly, the GlobalID field exists only to support that use case and should not be used for any other purpose (see note in field descriptions).Updates and Date of ProcessingConcurrent with CDTFA updates, approximately every two weeks, Last Processed: 12/17/2024 by Nick Santos using code path at https://github.com/CDT-ODS-DevSecOps/cdt-ods-gis-city-county/ at commit 0bf269d24464c14c9cf4f7dea876aa562984db63. It incorporates updates from CDTFA as of 12/12/2024. Future updates will include improvements to metadata and update frequency.
Click here to access the data directly from the Illinois State Geospatial Data Clearinghouse. These lidar data are processed Classified LAS 1.4 files, formatted to 2,117 individual 2500 ft x 2500 ft tiles; used to create Reflectance Images, 3D breaklines and hydro-flattened DEMs as necessary. Geographic Extent: Lake county, Illinois covering approximately 466 square miles. Dataset Description: WI Kenosha-Racine Counties and IL 4 County QL1 Lidar project called for the Planning, Acquisition, processing and derivative products of lidar data to be collected at a derived nominal pulse spacing (NPS) of 1 point every 0.35 meters. Project specifications are based on the U.S. Geological Survey National Geospatial Program Base Lidar Specification, Version 1.2. The data was developed based on a horizontal projection/datum of NAD83 (2011), State Plane, U.S Survey Feet and vertical datum of NAVD88 (GEOID12B), U.S. Survey Feet. Lidar data was delivered as processed Classified LAS 1.4 files, formatted to 2,117 individual 2500 ft x 2500 ft tiles, as tiled Reflectance Imagery, and as tiled bare earth DEMs; all tiled to the same 2500 ft x 2500 ft schema. Ground Conditions: Lidar was collected April-May 2017, while no snow was on the ground and rivers were at or below normal levels. In order to post process the lidar data to meet task order specifications and meet ASPRS vertical accuracy guidelines, Ayers established a total of 66 ground control points that were used to calibrate the lidar to known ground locations established throughout the WI Kenosha-Racine Counties and IL 4 County QL1 project area. An additional 195 independent accuracy checkpoints, 116 in Bare Earth and Urban landcovers (116 NVA points), 79 in Tall Grass and Brushland/Low Trees categories (79 VVA points), were used to assess the vertical accuracy of the data. These checkpoints were not used to calibrate or post process the data. Users should be aware that temporal changes may have occurred since this dataset was collected and that some parts of these data may no longer represent actual surface conditions. Users should not use these data for critical applications without a full awareness of its limitations. Acknowledgement of the U.S. Geological Survey would be appreciated for products derived from these data. These LAS data files include all data points collected. No points have been removed or excluded. A visual qualitative assessment was performed to ensure data completeness. No void areas or missing data exist. The raw point cloud is of good quality and data passes Non-Vegetated Vertical Accuracy specifications.Link Source: Illinois Geospatial Data Clearinghouse
Tags
Social system, socio-economic resources, justice, BES, Environmental Justice, Environmental disamentities, Zoning Board of Appeals
Summary
For use in the environmental injustices study of Baltimore relating to patterns of environmental disamenties in relation to low income/minority communities.
Description
This feature class layer is a point dataset of appeals to the Zoning Board of Appeals (ZBA) from 1938 to 1999 concerning identified environmental disamentities. The data was gathered from records from the Zoning Board of Appeals decisions since 1931 relating to environmental disamentities and to be used to examine environmental injustices involving low income/minority communities in Baltimore. To see if environmental injustices exist in Baltimore, this point layer will be overlayed with race/income data to determine if patterns of inequity exist. Points were placed manually using the associated addresses from the ZBA_master dataset. The ID number associated with each point is related to its appeal number from the Zoning Board of Appeals. Multiple points on the data layer have the same ZBA_ID number, making it a one-to-many relationship. This layer can be joined with the ZBA_master table using the "ZBA_point_relationship" and the field "ZBA_ID".
Credits
UVM Spatial Analysis Lab
Use limitations
None. There are no restrictions on the use of this dataset. The authors of this dataset make no representations of any kind, including but not limited to the warranties of merchantability or fitness for a particular use, nor are any such warranties to be implied with respect to the data.
Extent
West -76.708848 East -76.527906
North 39.371642 South 39.199548
This is part of a collection of 221 Baltimore Ecosystem Study metadata records that point to a geodatabase.
The geodatabase is available online and is considerably large. Upon request, and under certain arrangements, it can be shipped on media, such as a usb hard drive.
The geodatabase is roughly 51.4 Gb in size, consisting of 4,914 files in 160 folders.
Although this metadata record and the others like it are not rich with attributes, it is nonetheless made available because the data that it represents could be indeed useful.
A water right is a legal right to use surface or ground water under the Alaska Water Use Act (AS 46.15). A water right allows a specific amount of water from a specific water source to be diverted, impounded, or withdrawn for a specific use. When a water right is granted, it becomes appurtenant to the land where the water is being used for as long as the water is used. If the land is sold, the water right transfers with the land to the new owner, unless the Department of Natural Resources (DNR) approves its separation from the land. In Alaska, because water wherever it naturally occurs is a common property resource, landowners do not have automatic rights to ground water or surface water. For example, if a farmer has a creek running through his property, he will need a water right to authorize his use of a significant amount of water. Using water without a permit or certificate does not give the user a legal right to use the water. This shape file characterizes the geographic representation of point locations within the State of Alaska contained by the Surface Water Rights category. It has been extracted from data sets used to produce the State status plats. This data set includes cases noted on the digital status plats up to one day prior to data extraction. Each feature has an associated attribute record, including a Land Administration System (LAS) file-type and file-number which serves as an index to related LAS case-file information. Additional LAS case-file and customer information may be obtained at: http://www.dnr.state.ak.us/las/LASMenu.cfm Those requiring more information regarding State land records should contact the Alaska Department of Natural Resources Public Information Center directly.
Description of columns in the ArcGIS point file "Points for Maps" which provides the final statistics used to make the maps of mean daily water levels and maps of the 25th, 50th, and 75th percentiles of daily water levels during 2000–2009 in Miami-Dade County; and maps showing the differences in the statistics of water levels between 1990–1999 and 2000–2009.