Summary data of fixed broadband coverage by geographic area. License and Attribution: Broadband data from FCC Form 477, and data from the U.S. Census Bureau that are presented on this site are offered free and not subject to copyright restriction. Data and content created by government employees within the scope of their employment are not subject to domestic copyright protection under 17 U.S.C. § 105. See, e.g., U.S. Government Works. While not required, when using content, data, documentation, code and related materials from fcc.gov or broadbandmap.fcc.gov in your own work, we ask that proper credit be given. Examples include: • Source data: FCC Form 477 • Map layer based on FCC Form 477 • Code data based on broadbandmap.fcc.gov The geography look ups are created from the US census shapefiles, which are in Global Coordinate System North American Datum of 1983 (GCS NAD83). The coordinates do not get reprojected during processing. The "centroid_lng", "centroid_lat" columns in the lookup table are the exact values from the US census shapefile (INTPTLON, INTPTLAT). The "bbox_arr" column is calculated from the bounding box/extent of the original geometry in the shapefile; no reprojection or transformations are done to the geometry.

TIGER road data for the MSA. When compared to high-resolution imagery and other transportation datasets positional inaccuracies were observed. As a result caution should be taken when using this dataset. TIGER, TIGER/Line, and Census TIGER are registered trademarks of the U.S. Census Bureau. ZCTA is a trademark of the U.S. Census Bureau. The Census 2000 TIGER/Line files are an extract of selected geographic and cartographic information from the Census TIGER data base. The geographic coverage for a single TIGER/Line file is a county or statistical equivalent entity, with the coverage area based on January 1, 2000 legal boundaries. A complete set of census 2000 TIGER/Line files includes all counties and statistically equivalent entities in the United States, Puerto Rico, and the Island Areas. The Census TIGER data base represents a seamless national file with no overlaps or gaps between parts. However, each county-based TIGER/Line file is designed to stand alone as an independent data set or the files can be combined to cover the whole Nation. The Census 2000 TIGER/Line files consist of line segments representing physical features and governmental and statistical boundaries. The boundary information in the TIGER/Line files are for statistical data collection and tabulation purposes only; their depiction and designation for statistical purposes does not constitute a determination of jurisdictional authority or rights of ownership or entitlement. The Census 2000 TIGER/Line files do NOT contain the Census 2000 urban areas which have not yet been delineated. The files contain information distributed over a series of record types for the spatial objects of a county. There are 17 record types, including the basic data record, the shape coordinate points, and geographic codes that can be used with appropriate software to prepare maps. Other geographic information contained in the files includes attributes such as feature identifiers/census feature class codes (CFCC) used to differentiate feature types, address ranges and ZIP Codes, codes for legal and statistical entities, latitude/longitude coordinates of linear and point features, landmark point features, area landmarks, key geographic features, and area boundaries. The Census 2000 TIGER/Line data dictionary contains a complete list of all the fields in the 17 record types. 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.

Individual boundary polylines were created by first making a point shapefile of the line endpoints or a series of points, then converting the points to a polyline. The point/polyline conversion was done using XTools 'Make One Polyline from Points' tool. Point locations were based on latitude/longitude coordinates given in the technical report or geographic landmark (i.e. islands, points, state/international boundary lines, etc.). Points requiring an azimuth bearing were created in a projected view (UTM Zone 17 NAD27) using the Distance and Azimuth Tools v. 1.6 extension developed by Jenness Enterprises.The polyline shapefiles created in step 1 and an existing polyline shapefile of the international boundary were merged together using the ArcView GeoProcessing Wizard.The shapefile generated in step 2 was converted to a line coverage using the ArcToolbox Conversion Tools - Feature Class to Coverage.The line coverage topology was cleaned and updated using the ArcInfo Workstation CLEAN (dangle length and fuzzy tolerance both set to 0.001) and BUILD commands.The boundary line coverage and an existing Lake Erie shoreline shapefile (derived from ESRI 100k data) were merged together using the ArcView GeoProcessing Wizard.The shapefile generated in step 5 was converted to a line coverage using the ArcToolbox Conversion Tools - Feature Class to Coverage.Topology of the boundary/shoreline coverage was cleaned and updated using the ArcInfo Workstation CLEAN (dangle length and fuzzy tolerance both set to 0.00001) and BUILD commands. BUILD was done for both line and polygon topology.The polygon feature from the coverage generate in step 7 was converted to a shapefile using Theme\Convert to Shapefile in ArcView.

The seamless, county-wide parcel layer was digitized from official Assessor Parcel (AP) Maps which were originally maintained on mylar sheets and/or maintained as individual Computer Aided Design (CAD) drawing files (e.g., DWG). The CRA office continues to maintain the official AP Maps in CAD drawings and Information Systems Department/Geographic Information Systems (ISD/GIS) staff apply updates from these maps to the seamless parcel base in the County’s Enterprise GIS. This layer is a partial view of the Information Sales System (ISS) extract, a report of property characteristics taken from the County’s Megabyte Property Tax System (MPTS). This layer may be missing some attributes (e.g., Owner Name) which may not be published to the Internet due to privacy conditions under the California Public Records Act (CPRA). Please contact the Clerk-Recorder-Assessor (CRA) office at (707) 565-1888 for information on availability, associated fees, and access to other versions of Sonoma County parcels containing additional property characteristics.The seamless parcel layer is updated and published to the Internet on a monthly basis.The seamless parcel layer was developed from the source data using the general methodology outlined below. The mylar sheets were scanned and saved to standard image file format (e.g., TIFF). The individual scanned maps or CAD drawing files were imported into GIS software and geo-referenced to their corresponding real-world locations using high resolution orthophotography as control. The standard approach was to rescale and rotate the scanned drawing (or CAD file) to match the general location on the orthophotograph. Then, appropriate control points were selected to register and rectify features on the scanned map (or CAD drawing file) to the orthophotography. In the process, features in the scanned map (or CAD drawing file) were transformed to real-world coordinates, and line features were created using “heads-up digitizing” and stored in new GIS feature classes. Recommended industry best practices were followed to minimize root mean square (RMS) error in the transformation of the data, and to ensure the integrity of the overall pattern of each AP map relative to neighboring pages. Where available Coordinate Geometry (COGO) & survey data, tied to global positioning systems (GPS) coordinates, were also referenced and input to improve the fit and absolute location of each page. The vector lines were then assembled into a polygon features, with each polygon being assigned a unique identifier, the Assessor Parcel Number (APN). The APN field in the parcel table was joined to the corresponding APN field in the assessor property characteristics table extracted from the MPTS database to create the final parcel layer. The result is a seamless parcel land base, each parcel polygon coded with a unique APN, assembled from approximately 6,000 individual map page of varying scale and accuracy, but ensuring the correct topology of each feature within the whole (i.e., no gaps or overlaps). The accuracy and quality of the parcels varies depending on the source. See the fields RANK and DESCRIPTION fields below for information on the fit assessment for each source page. These data should be used only for general reference and planning purposes. It is important to note that while these data were generated from authoritative public records, and checked for quality assurance, they do not provide survey-quality spatial accuracy and should NOT be used to interpret the true location of individual property boundary lines. Please contact the Sonoma County CRA and/or a licensed land surveyor before making a business decision that involves official boundary descriptions.

This is a collection of all GPS- and computer-generated geospatial data specific to the Alpine Treeline Warming Experiment (ATWE), located on Niwot Ridge, Colorado, USA. The experiment ran between 2008 and 2016, and consisted of three sites spread across an elevation gradient. Geospatial data for all three experimental sites and cone/seed collection locations are included in this package. ––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––– Geospatial files include cone collection, experimental site, seed trap, and other GPS location/terrain data. File types include ESRI shapefiles, ESRI grid files or Arc/Info binary grids, TIFFs (.tif), and keyhole markup language (.kml) files. Trimble-imported data include plain text files (.txt), Trimble COR (CorelDRAW) files, and Trimble SSF (Standard Storage Format) files. Microsoft Excel (.xlsx) and comma-separated values (.csv) files corresponding to the attribute tables of many files within this package are also included. A complete list of files can be found in this document in the “Data File Organization” section in the included Data User's Guide. Maps are also included in this data package for reference and use. These maps are separated into two categories, 2021 maps and legacy maps, which were made in 2010. Each 2021 map has one copy in portable network graphics (.png) format, and the other in .pdf format. All legacy maps are in .pdf format. .png image files can be opened with any compatible programs, such as Preview (Mac OS) and Photos (Windows). All GIS files were imported into geopackages (.gpkg) using QGIS, and double-checked for compatibility and data/attribute integrity using ESRI ArcGIS Pro. Note that files packaged within geopackages will open in ArcGIS Pro with “main.” preceding each file name, and an extra column named “geom” defining geometry type in the attribute table. The contents of each geospatial file remain intact, unless otherwise stated in “niwot_geospatial_data_list_07012021.pdf/.xlsx”. This list of files can be found as an .xlsx and a .pdf in this archive. As an open-source file format, files within gpkgs (TIFF, shapefiles, ESRI grid or “Arc/Info Binary”) can be read using both QGIS and ArcGIS Pro, and any other geospatial softwares. Text and .csv files can be read using TextEdit/Notepad/any simple text-editing software; .csv’s can also be opened using Microsoft Excel and R. .kml files can be opened using Google Maps or Google Earth, and Trimble files are most compatible with Trimble’s GPS Pathfinder Office software. .xlsx files can be opened using Microsoft Excel. PDFs can be opened using Adobe Acrobat Reader, and any other compatible programs. A selection of original shapefiles within this archive were generated using ArcMap with associated FGDC-standardized metadata (xml file format). We are including these original files because they contain metadata only accessible using ESRI programs at this time, and so that the relationship between shapefiles and xml files is maintained. Individual xml files can be opened (without a GIS-specific program) using TextEdit or Notepad. Since ESRI’s compatibility with FGDC metadata has changed since the generation of these files, many shapefiles will require upgrading to be compatible with ESRI’s latest versions of geospatial software. These details are also noted in the “niwot_geospatial_data_list_07012021” file.

In 2002 and 2003, the U.S. Geological Survey (USGS), Woods Hole Coastal and Marine Science Center (WHCMSC), in cooperation with the National Oceanic and Atmospheric Administration (NOAA), conducted three exploration cruises (USGS Cruise 02051, NOAA RB0208, September 24 to 30, 2002; USGS Cruise 03008, NOAA RB0303, February 18 to March 7, 2003 and USGS Cruise 03032, NOAA RB0305, August 28 to September 4, 2003). These cruises mapped for the first time the morphology of this entire tectonic plate boundary stretching from the Dominican Republic in the west to the Lesser Antilles in the east, a distance of approximately 700 kilometers (430 miles). Observations from these three exploration cruises, coupled with computer modeling and published Global Positioning System (GPS) results and earthquake focal mechanisms have provided new information that is changing the evaluation of the seismic and tsunami hazard from this plate boundary. The observations collected during these cruises also contributed to the basic understanding of the mechanisms that govern plate tectonics, in this case, the creation of the island of Puerto Rico and the deep trench north of it. Results of the sea floor mapping have been an important component of the study of tsunami and earthquake hazards to the northeastern Caribbean and the U.S. Atlantic coast off the United States. For additional information on the cruises see: http://woodshole.er.usgs.gov/operations/ia/public_ds_info.php?fa=2002-051-FA http://woodshole.er.usgs.gov/operations/ia/public_ds_info.php?fa=2002-051-FA http://woodshole.er.usgs.gov/operations/ia/public_ds_info.php?fa=2002-051-FA

Documented March 19, 2023

!!NEW!!!

GeoDAR reservoirs were registered to the drainage network! Please see the auxiliary data "GeoDAR-TopoCat" at https://zenodo.org/records/7750736. "GeoDAR-TopoCat" contains the drainage topology (reaches and upstream/downstream relationships) and catchment boundary for each reservoir in GeoDAR, based on the algorithm used for Lake-TopoCat (doi:10.5194/essd-15-3483-2023).

Documented April 1, 2022

Citation

Wang, J., Walter, B. A., Yao, F., Song, C., Ding, M., Maroof, A. S., Zhu, J., Fan, C., McAlister, J. M., Sikder, M. S., Sheng, Y., Allen, G. H., Crétaux, J.-F., and Wada, Y.: GeoDAR: georeferenced global dams and reservoirs database for bridging attributes and geolocations. Earth System Science Data, 14, 1869–1899, 2022, https://doi.org/10.5194/essd-14-1869-2022.

Please cite the reference above (which was fully peer-reviewed), NOT the preprint version. Thank you.

Contact

Dr. Jida Wang, jidawang@ksu.edu, gdbruins@ucla.edu

Data description and components

Data folder “GeoDAR_v10_v11” (.zip) contains two consecutive, peer-reviewed versions (v1.0 and v1.1) of the Georeferenced global Dams And Reservoirs (GeoDAR) dataset:

GeoDAR_v10_dams (in both shapefile format and the comma-separated values (csv) format): GeoDAR version 1.0, including 22,560 dam points georeferenced based on the World Register of Dams (WRD), the International Commission on Large Dams (ICOLD; https://www.icold-cigb.org; last access on March 13th, 2019).

GeoDAR_v11_dams (in both shapefile and csv): GeoDAR version 1.1 dam points, including 24,783 dams which harmonized GeoDAR_v10_dams and the Global Reservoir and Dam Database (GRanD) v1.3 (Lehner et al., 2011).

GeoDAR_v11_reservoirs (in shapefile): GeoDAR version 1.1 reservoirs, including 21,515 reservoir polygons retrieved by associating GeoDAR_v11_dams with GRanD v1.3 reservoirs, HydroLAKES v1.0 (Messager et al., 2016), and the UCLA Circa 2015 Lake Inventory (Sheng et al., 2016). The reservoir retrieval follows a one-to-one relationship between dams and reservoirs.

As by-products of GeoDAR harmonization, folder “GeoDAR_v10_v11” also contains:

GRanD_v13_issues.csv: This file contains the original records of all 7,320 dam points in GRanD v1.3, with 94 of them marked by our identified issues and suggested corrections. These 94 records are placed at the beginning of this table. They include 89 records showing possible georeferencing and/or attribute errors, and another 5 records documented as subsumed or replaced. Our added fields start from column BG and include:

“Issue”: main issue(s) of this record

“Description”: more detailed explanation of the issue

“Lat_corrected”: suggested correction for latitude (if any) in decimal degree

“Lon_corrected”: suggested correction for longitude (if any) in decimal degree

“Correction_source”: correction source(s)

“Harmonized”: whether this GRanD dam was harmonized in GeoDAR v1.1 and the reason.

Wada_et_al_2017_harmonized.csv: This csv file contains the original records of all 139 georeferenced large dams/reservoirs in Wada et al. (2017; doi:10.1007/s10712-016-9399-6), with our revised storage capacities and spatial coordinates for data harmonization. Our added fields start from column E and include:

Revised_capacity_km3: Our revised reservoir storage capacity in cubic kilometers used for harmonization

Revised_lat: Revised latitude in decimal degree

Revised_lon: Revised longitude in decimal degree

Verification_notes: Description of the issues, verification sources, and other information used for harmonization.

Attribute description

Attribute

Description and values

v1.0 dams (file name: GeoDAR_v10_dams; format: comma-separated values (csv) and point shapefile)

id_v10

Dam ID for GeoDAR version 1.0 (type: integer). Note this is not the same as the International Code in ICOLD WRD but is linked to the International Code via encryption.

lat

Latitude of the dam point in decimal degree (type: float) based on datum World Geodetic System (WGS) 1984.

lon

Longitude of the dam point in decimal degree (type: float) on WGS 1984.

geo_mtd

Georeferencing method (type: text). Unique values include “geo-matching CanVec”, “geo-matching LRD”, “geo-matching MARS”, “geo-matching NID”, “geo-matching ODC”, “geo-matching ODM”, “geo-matching RSB”, “geocoding (Google Maps)”, and “Wada et al. (2017)”. Refer to Table 2 in Wang et al. (2022) for abbreviations.

qa_rank

Quality assurance (QA) ranking (type: text). Unique values include “M1”, “M2”, “M3”, “C1”, “C2”, “C3”, “C4”, and “C5”. The QA ranking provides a general measure for our georeferencing quality. Refer to Supplementary Tables S1 and S3 in Wang et al. (2022) for more explanation.

rv_mcm

Reservoir storage capacity in million cubic meters (type: float). Values are only available for large dams in Wada et al. (2017). Capacity values of other WRD records are not released due to ICOLD’s proprietary restriction. Also see Table S4 in Wang et al. (2022).

val_scn

Validation result (type: text). Unique values include “correct”, “register”, “mismatch”, “misplacement”, and “Google Maps”. Refer to Table 4 in Wang et al. (2022) for explanation.

val_src

Primary validation source (type: text). Values include “CanVec”, “Google Maps”, “JDF”, “LRD”, “MARS”, “NID”, “NPCGIS”, “NRLD”, “ODC”, “ODM”, “RSB”, and “Wada et al. (2017)”. Refer to Table 2 in Wang et al. (2022) for abbreviations.

qc

Roles and name initials of co-authors/participants during data quality control (QC) and validation. Name initials are given to each assigned dam or region and are listed generally in chronological order for each role. Collation and harmonization of large dams in Wada et al. (2017) (see Table S4 in Wang et al. (2022)) were performed by JW, and this information is not repeated in the qc attribute for a reduced file size. Although we tried to track the name initials thoroughly, the lists may not be always exhaustive, and other undocumented adjustments and corrections were most likely performed by JW.

v1.1 dams (file name: GeoDAR_v11_dams; format: comma-separated values (csv) and point shapefile)

id_v11

Dam ID for GeoDAR version 1.1 (type: integer). Note this is not the same as the International Code in ICOLD WRD but is linked to the International Code via encryption.

id_v10

v1.0 ID of this dam/reservoir (as in id_v10) if it is also included in v1.0 (type: integer).

id_grd_v13

GRanD ID of this dam if also included in GRanD v1.3 (type: integer).

lat

Latitude of the dam point in decimal degree (type: float) on WGS 1984. Value may be different from that in v1.0.

lon

Longitude of the dam point in decimal degree (type: float) on WGS 1984. Value may be different from that in v1.0.

geo_mtd

Same as the value of geo_mtd in v1.0 if this dam is included in v1.0.

qa_rank

Same as the value of qa_rank in v1.0 if this dam is included in v1.0.

val_scn

Same as the value of val_scn in v1.0 if this dam is included in v1.0.

val_src

Same as the value of val_src in v1.0 if this dam is included in v1.0.

rv_mcm_v10

Same as the value of rv_mcm in v1.0 if this dam is included in v1.0.

rv_mcm_v11

Reservoir storage capacity in million cubic meters (type: float). Due to ICOLD’s proprietary restriction, provided values are limited to dams in Wada et al. (2017) and GRanD v1.3. If a dam is in both Wada et al. (2017) and GRanD v1.3, the value from the latter (if valid) takes precedence.

har_src

Source(s) to harmonize the dam points. Unique values include “GeoDAR v1.0 alone”, “GRanD v1.3 and GeoDAR 1.0”, “GRanD v1.3 and other ICOLD”, and “GRanD v1.3 alone”. Refer to Table 1 in Wang et al. (2022) for more details.

pnt_src

Source(s) of the dam point spatial coordinates. Unique values include “GeoDAR v1.0”, “original GRanD”, “adjusted GRanD” (meaning the original dam point location in GRanD has been adjusted to improve the accuracy), and “corrected GRanD” (meaning the original point in GRanD was misplaced and has been corrected). Also see Table S5 in Wang et al. (2022).

qc

Roles and name initials of co-authors/participants during data QC, validation, and other manual operations. Name initials are given to each assigned dam or region and are listed generally in chronological order for each role. Correction of GRanD (see Table S5 in Wang et al. (2022)) and reservoir polygon QC were performed by JW, and this information is not repeated in the qc attribute to reduce the file size. Although we tried to track the name initials thoroughly, the lists may not be always exhaustive, and other undocumented adjustments and corrections were most likely performed by JW.

v1.1 reservoirs (file name: GeoDAR_v11_reservoirs; format: polygon shapefile)

plg_src

Source of the retrieved reservoir polygon (type: text). Unique values include “GRanD v1.3”, “HydroLAKES v1.0”, and “UCLA Circa 2015”. Refer to Table 1 in Wang et al. (2022) for more details.

plg_a_km2

Area of the retrieved reservoir polygon in square kilometres (calculated based on the cylindrical equal area projection on datum WGS 1984).

All other attributes in v1.1 dams.

Data and code availability

GeoDAR v1.0 (dam points) and v1.1 (both dam points and reservoir polygons) are available under the Creative Commons Attribution 4.0 International (CC-BY 4.0) license (https://creativecommons.org/licenses/by/4.0).

Any user who would like to link GeoDAR features to the proprietary WRD attributes the user has purchased in advance from ICOLD should contact the corresponding author JW.

Python scripts for geo-matching, geocoding, and reservoir

The district (Category C) municipalities are municipalities that are comprised of local (Category B) municipalities. The Metropolitan (Category A) Municipalities are municipalities with the major cities as the core (e.g. City of Johannesburg) and they are outside the District Municipalities. When the boundaries of local municipalities change and affect the boundary of district municipalities, the new district municipal boundary is generated. In the District Municipalities 2018 shapefile there are 44 District Municipalities and 8 Metropolitan Municipalities. Note that Metropolitan Municipalities are included in the District Municipalities shapefile to ensure that the layer is continuous throughout the country. If the Metropolitan Municipalities were left out, there will be void spaces in the layer. The topology of the features has been checked to eliminate duplications of vertices and ensure the integrity of the feature geometry. The projection of the feature class is Geographic (Lat/Lon) andif one has to calculate the area of features, it must be transformed to UTM Projection and metres be used as units of measurements.

This repository contains data associated with the paper: Cook, C. W., Byrne, S., 2025. Wavelet Analysis of Concentric Crater Fill Surface Ridges. Icarus (accepted).The folder Input_Data contains the following subfolders:CCF_HiRISE_profiles, which includes subfolders for image, orthoimage, DTM, and hillshade profiles. These in turn contain subfolders such as the following (not all subfolders included for each):shapefiles: shapefiles for profiles, including the drawn profiles (filenames include image/DTM name and end with _profiles), profiles parallel to the drawn profiles (filenames end with _profiles_parallel_n6_5m), points along all profiles (filenames end with _profiles_parallel_n6_5m_points), and points along profiles with the image DN, elevation, or hillshade raster values extracted (filenames end with _profiles_parallel_n6_5m_points_DN, _profiles_parallel_n6_5m_points_ELEV, profiles_parallel_n6_5m_points_VAL). Note that any profile ID ending with 01 was not used for the final analysis in the paper (only those numbered 02 or greater were included).profiles_with_geom: CSV files (filenames end with e.g. _profiles_parallel_n6_5m_points_DN_geom) which include the IDs for each profile, number from 0-5 indicating parallel profile number, offset distance between each parallel profile and the drawn profile in meters, distances along profile in meters, angle of the profile measured from north (in degrees), raster values extracted along profiles, and x and y coordinates for each point (in the map projection corresponding to the relevant image, orthoimage, DTM, or hillshade).profiles_lat_lon_elev: CSV files for each image including the profile ID, latitude, longitude, and mean elevation of the associated CCF (from Levy et al. 2014 data).profiles_fillthick: CSV files for each image including the profile ID and estimated fill thickness (in km) for the associated CCF (from Levy et al. 2014 data).profiles_angle: CSV files for each image including the profile ID and the angle of each profile from north (in degrees).CCF_crater_centers, which includes subfolders for files using map projections associated with the images and with orthoimages. These in turn contain the following subfolders:shapefiles: shapefiles for the center point of the crater associated with the CCF (filenames end with _centerpoint).csv_with_geom: CSV files (filenames end with _centerpoint_geom) including the x and y coordinates of the point at the center of the crater for the associated CCF (columns labeled xcoord and ycoord), the crater diameter (column labeled DIAM_CIRC_) from Robbins and Hynek 2012 data, and other information (unused) from the Robbins and Hynek 2012 database.miscellaneous_information, which includes the following files:CCF_HiRISE_profiles_categorization_v2: CSV file including image names, profile IDs, and the corresponding values for each category described in the methods (“Orientation Strength” and “Continuity” columns have values from 1-3 which correspond to low-high categorization; “Packetized” and “Distinguished Primarily by Negative Relief” columns have either y or n (yes or no) values)avgcategories_latlon: CSV file with latitude, longitude, and average orientation and continuity category values for profiles in each imagesCCF_HiRISE_image_name_lat_lon: CSV file with image names and center latitude and longitude for the CCF associated with each imageCCF_HiRISE_multiple_image_sites: CSV file with names of two images for CCF sites where two images were usedDTM_image_correspondence (and similar image_orthoimage_correspondence): CSV file including DTMs used for the study with the name of the corresponding image used (or images and corresponding orthoimages used)HiRISE_image_list, HiRISE_orthoimage_list, HiRISE_DTM_list: txt files with lists of all images, orthoimage, and DTMs used.The folder Output_Data contains subfolders for image, orthoimage, DTM, and hillshade wavelet analysis output. These in turn contain subfolders such as the following (not all subfolders included for each):significant_wavelengths_and_overlaps, which includes the following types of files:filenames containing summary_peaksigpow: CSV files with a summary of the significant wavelengths identified for each profile. This summary includes the wavelengths (in meters), the global wavelet power at each wavelength, length of the longest individual segment with significant power for each wavelength (relative to the wavelength), length of the longest individual segment with significant power for each wavelength (in meters), total distance over which each wavelength has significant power (relative to the wavelength), and the total distance over which each wavelength has significant power (in meters).filenames containing summary_overlap: CSV files with a summary of the significant wavelengths identified for each profile that overlap over some distance. This summary includes (for each pair of overlapping wavelengths): the shorter wavelength (in meters), the longer wavelength (in meters), the maximum continuous distance over which the wavelengths overlap (in meters), the maximum continuous distance over which the wavelengths overlap (relative to the longer wavelength), the total distance over which the wavelengths overlap (in meters), and the total distance over which the wavelengths overlap (relative to the longer wavelength).profile_crater_geom, which contains the following type of file:CSV files for each profile including: the x and y coordinates for each point along the profile, the radial distance from the center of the crater to the point in meters, the radial distance from the center of the crater divided by the crater diameter, the angle between each point and the center of the crater (measured from east, -180° to 180°), and for each significant wavelength identified in the profile (ordered shortest to longest), a zero or one value indicating whether the wavelength is significant at that point along the profile.figures, which contains the following type of file:figures (PNG file type) for each profile showing the profile I/F or elevation values vs distance (a), the wavelet power spectrum (b), the global wavelet power spectrum (c), and a plot of the length of the longest segment with significant power for each wavelength (d).overlaps_summaries, which contains the following types of files:significant_wavelengths_overlaps_evaluation_max_seg_dist: CSV files summarizing all profiles with overlapping wavelengths, including the image and profile name, shorter wavelength (meters), longer wavelength (meters), maximum continuous distance over which they overlap (relative to the longer wavelength), total distance over which they overlap (relative to the longer wavelength), and the ratio of the longer to the shorter wavelength. These files include just those pairs of wavelengths with a maximum continuous overlapping distance (relative to the longer wavelength) of at least 3.significant_wavelengths_overlaps_evaluation_sum_seg_dist: same as the above, but these files include those pairs of wavelengths with a total overlapping distance (relative to the longer wavelength) of at least 3.other, which contains the following files:filename containing lat_lon_minwavelen_maxwavelen: CSV file summarizing latitude, longitude, minimum wavelength (m), and maximum wavelength (m) identified for each CCF site.filename containing lat_lon_stdev: CSV file summarizing latitude, longitude, and standard deviation (m) of identified wavelengths for each CCF site.filename containing lat_lon_fillthick: CSV file summarizing the latitude, longitude, and estimated fill thickness (km; from Levy et al. 2014 data) for each CCF site.filename containing ks_es_theta0: CSV file summarizing statistical tests comparing the distributions of angular locations of profiles within craters for all profiles taken and for those with significant wavelengths identified (in both hemispheres, northern hemisphere only, and southern hemisphere only). This includes the number of profiles taken, the number of profiles for which significant wavelengths were identified, the Kolmogorov-Smirnov test statistic values, the corresponding KS test p-values, the Epps-Singleton test statistic values, and the corresponding ES test p-values.Preview_image.png corresponds to DTEEC_002175_2210_001410_2210_A01_EC02_n6_5m_wpsavg_sigavg_abspow_overnumwavelen3.png” in CCF_Ridges_Wavelet_Analysis/Output_Data/DTM_wavelet_output/figures.For inquiries regarding the contents of this dataset, please contact the Corresponding Author listed in the README.txt file. Administrative inquiries (e.g., removal requests, trouble downloading, etc.) can be directed to data-management@arizona.edu

Purpose:This feature layer describes the boundaries of Proposed Critical Habitat for the Rusty Patched Bumble Bee in Virginia and West Virginia.Source & Date:Data was downloaded from Regulations.gov, Document FWS-R3-ES-2024-0132-0016: CORRECTED_Rusty Patched Bumble Bee Critical Habitat Plot Points. Posted by the Fish and Wildlife Service on Dec 6, 2024 and accessible here as of 1/16/2025.Processing:The data was downloaded as a list of Latitude and Longitude coordinates in a PDF document. The PPDF was converted to Microsoft Excel format using Nitro Pro PDF editor. Data was cleaned of extra tabs, spaces, etc., given an OBJECTID field and saved as a comma-separated values (CSV) text file. The CSV file was loaded into ArcGIS Pro and converted to a point feature class using Latitude and Longitude as Y & X coordinates, respectively. The point featureclass was converted to polyline using the Points to Line script in Data management Tools - Features tool set. The polyline feature was converted to Polygon using Feature to Polygon (again in Features tool set). Fields for Square Miles (SqMi) and Acres were added and calculated with Calculate Geometry. The polygon feature class was exported to shapefile, zipped and uploaded to ArcGIS Online, where it was published as a feature layer.Symbology:Varies - default is medium blue polygon with dark gray outline.

ps-places-metadata-v1.01

SUMMARY

This dataset comprises a pair of layers, (points and polys) which attempt to better locate "populated places" in NZ. Populated places are defined here as settled areas, either urban or rural where densitys of around 20 persons per hectare exist, and something is able to be seen from the air.

RATIONALE

The only liberally licensed placename dataset is currently LINZ geographic placenames, which has the following drawbacks: - coordinates are not place centers but left most label on 260 series map - the attributes are outdated

METHODOLOGY

This dataset necessarily involves cleaving the linz placenames set into two, those places that are poplulated, and those unpopulated. Work was carried out in four steps. First placenames were shortlisted according to the following criterion: - all places that rated at least POPL in the linz geographic places layer, ie POPL, METR or TOWN or USAT were adopted. - Then many additional points were added from a statnz meshblock density analysis.
- Finally remaining points were added from a check against linz residential polys, and zenbu poi clusters.

Spelling is broadly as per linz placenames, but there are differences for no particular reason. Instances of LINZ all upper case have been converted to sentance case. Some places not presently in the linz dataset are included in this set, usually new places, or those otherwise unnamed. They appear with no linz id, and are not authoritative, in some cases just wild guesses.

Density was derived from the 06 meshblock boundarys (level 2, geometry fixed), multipart conversion, merging in 06 usually resident MB population then using the formula pop/area*10000. An initial urban/rural threshold level of 0.6 persons per hectare was used.

Step two was to trace the approx extent of each populated place. The main purpose of this step was to determine the relative area of each place, and to create an intersection with meshblocks for population. Step 3 involved determining the political center of each place, broadly defined as the commercial center.

Tracing was carried out at 1:9000 for small places, and 1:18000 for large places using either bing or google satellite views. No attempt was made to relate to actual town 'boundarys'. For example large parks or raceways on the urban fringe were not generally included. Outlying industrial areas were included somewhat erratically depending on their connection to urban areas.

Step 3 involved determining the centers of each place. Points were overlaid over the following layers by way of a base reference:

a. original linz placenames b. OSM nz-locations points layer c. zenbu pois, latest set as of 5/4/11 d. zenbu AllSuburbsRegions dataset (a heavily hand modified) LINZ BDE extract derived dataset courtesy Zenbu. e. LINZ road-centerlines, sealed and highway f. LINZ residential areas, g. LINZ building-locations and building footprints h. Olivier and Co nz-urban-north and south

Therefore in practice, sources c and e, form the effective basis of the point coordinates in this dataset. Be aware that e, f and g are referenced to the LINZ topo data, while c and d are likely referenced to whatever roading dataset google possesses. As such minor discrepencys may occur when moving from one to the other.

Regardless of the above, this place centers dataset was created using the following criteria, in order of priority:

• attempts to represent the present (2011) subjective 'center' of each place as defined by its commercial/retail center ie. mainstreets where they exist, any kind of central retail cluster, even a single shop in very small places.
• the coordinate is almost always at the junction of two or more roads.
• most of the time the coordinate is at or near the centroid of the poi cluster
• failing any significant retail presence, the coordinate tends to be placed near the main road junction to the community.
• when the above criteria fail to yield a definitive answer, the final criteria involves the centroids of: . the urban polygons . the clusters of building footprints/locations.

To be clear the coordinates are manually produced by eye without any kind of computation. As such the points are placed approximately perhaps plus or minus 10m, but given that the roads layers are not that flash, no attempt was made to actually snap the coordinates to the road junctions themselves.

The final step involved merging in population from SNZ meshblocks (merge+sum by location) of popl polys). Be aware that due to the inconsistent way that meshblocks are defined this will result in inaccurate populations, particular small places will collect population from their surrounding area. In any case the population will generally always overestimate by including meshblocks that just nicked the place poly. Also there are a couple of dozen cases of overlapping meshblocks between two place polys and these will double count. Which i have so far made no attempt to fix.

Merged in also tla and regions from SNZ shapes, a few of the original linz atrributes, and lastly grading the size of urban areas according to SNZ 'urban areas" criteria. Ie: class codes:

1. Not used.
2. main urban area 30K+
3. secondary urban area 10k-30K
4. minor urban area 1k-10k
5. rural center 300-1K
6. village -300

Note that while this terminology is shared with SNZ the actual places differ owing to different decisions being made about where one area ends an another starts, and what constiutes a suburb or satellite. I expect some discussion around this issue. For example i have included tinwald and washdyke as part of ashburton and timaru, but not richmond or waikawa as part of nelson and picton. Im open to discussion on these.

No attempt has or will likely ever be made to locate the entire LOC and SBRB data subsets. We will just have to wait for NZFS to release what is thought to be an authoritative set.

PROJECTION

Shapefiles are all nztm. Orig data from SNZ and LINZ was all sourced in nztm, via koordinates, or SNZ. Satellite tracings were in spherical mercator/wgs84 and converted to nztm by Qgis. Zenbu POIS were also similarly converted.

ATTRIBUTES

Shapefile: Points id : integer unique to dataset name : name of popl place, string class : urban area size as above. integer tcode : SNZ tla code, integer rcode : SNZ region code, 1-16, integer area : area of poly place features, integer in square meters. pop : 2006 usually resident popluation, being the sum of meshblocks that intersect the place poly features. Integer lid : linz geog places id desc_code : linz geog places place type code

Shapefile: Polygons gid : integer unique to dataset, shared by points and polys name : name of popl place, string, where spelling conflicts occur points wins area : place poly area, m2 Integer

LICENSE

Clarification about the minorly derived nature of LINZ and google data needs to be sought. But pending these copyright complications, the actual points data is essentially an original work, released as public domain. I retain no copyright, nor any responsibility for data accuracy, either as is, or regardless of any changes that are subsequently made to it.

Peter Scott 16/6/2011

v1.01 minor spelling and grammar edits 17/6/11

The outer boundary of the continental shelf extends from the point in the Idefjord, where the cadastral area no longer reaches the agreed delimitation with Norway, to a point on the boundary line with Finland with latitude 65° 35′ N. Around the island of Brand in the Åland Sea, the border follows the baselines. The inner boundary of the continental shelf is defined by the (sea) outermost cadastral boundaries. These limits are rarely set and are therefore not reported on the basis of the new law. There are also areas in some of the large lakes that are not divided into real estate.

The following attributes are located in the point shape file: Serial number — Sequencing number of continental shelf points (CP). Order No_KP — Sequencing number of significant points on the outer boundary line of the continental shelf. Latitude & Longitude — All points along the boundary are described by geographical coordinates in latitude and longitude expressed in the reference system SWEREF 99 partly in degrees and decimal minutes as stated in the law and partly in decimal degrees. Point type — The following point types exist: • cut-off point agreed with another State (CP), with the exception of points on the island of Market, for which there is no agreement with another State, • segmented point on a straight geodetic line or on a rhumb line between: two breakpoints (MP), and • point on the centreline of the Sound described by the coordinates on 27 November 2014 presented this line in the Swedish Maritime Administration’s chart database (ML). Point name — Names where this occurs (applies to agreed points on national borders). Source — Act (2017:1272) on Sweden’s maritime territory and zones. Unique ID — A unique ID added by the Swedish Maritime Administration.

The following attributes are available in the line shape file: Source — Act (2017:1272) on Sweden’s maritime territory and zones.

September 2017 OS Code-Point Open for Greater London and London boroughs are downloadable via the links below.

OS Code-Point Open provides a National Grid coodinate for a point within each postcode unit (e.g. SE1 2AA) in Great Britain.There are approximately 1.6 million postcode units in the UK and each contains an average of 15 adjoining addresses. It also contains a number of columns of attributes which provide information about each postcode unit, including local authority area codes down to ward level and National Health Service.

The geographic extent of the Code-Point dataset below has been limited to the Greater London area as well as extracts for the City of London and the 32 London boroughs individually. In addition to conventional CSV file format, the dataset is also available as ESRI shapefile format (.shp) for ease of use with Geographical Information Systems (GIS) for visualisation and further analysis.

Key attributes: postcode unit, easting, northing, NHS health authority code and administrative codes

Coverage: Greater London and 33 individual London borough.

Format: Comma separated values (.csv) & Esri shapefile (.shp)

External link: https://www.ordnancesurvey.co.uk/business-and-government/products/code-point-open.html

This dataset represents all 827,933 block-faces in Canada for the 1996 census. The dataset was designed for geocoding and census data extraction and it covers 43 urban centres in Canada.

A block-face represents one side of a street between two consecutive features intersecting that street. The dataset includes attribute information for street names (including street types and direction), address ranges, geographic codes for linkages with other census boundaries, geographic coordinates, and population and dwelling counts from the 1996 Census. They are displayed on a map via their representative point, which is the geographic coordinate located at the mid-point of the block-face, set back a perpendicular distance of 22, 11, 5, or 1 metre from the street centre line.

The original dataset is available from Statistics Canada as a text file (.txt). For viewing in Scholars GeoPortal, the dataset was converted from this original format into a Shapefile using the point coordinates available for each record. Each point is the population centre of an Enumeration Area.

The original data, and other supporting files and documentation, are available as additional downloads from Scholars GeoPortal.

The Swedish Maritime Territory and Maritime Zones Act (2017:1272) applies from 1 March 2018 Baselines and boundaries are reported with all coordinates in annexes to the Act. The lines defining the boundaries have been divided into shorter segments to be correctly accounted for in existing map projections. Baseline points, points on the low-water line and the low-water lake have been inspected and measured and form the basis for the calculation of the boundary of the maritime territory in the sea and the boundary of the adjacent zone. Straight baselines run between baseline points located on the low-water coastline (-0.5 metres RH2000) and follow the main direction of the coast. Normal baselines occur along certain parts of the coasts of Skåne, Öland and Gotland and follow the low-water line along the coastline where we do not have straight baselines. The points on the low-water line are located on normal baselines and have been selected where the position is expected to affect the calculation of the boundary of the sea territory. Low-water inserts are located outside the baselines and have been selected on a corresponding basis.

The following attributes are located in the point shape file: Ordernr_parts — Reference number of the baseline points (BP) for the respective sub-distance. Sub-distance — the baselines are presented with the following sections: Land and Öland, Gotland including Fårö and Lilla Karlsö, Gotska Sandön, Stora Karlsö, Brand, Brandshällarna. Point number_name — Number and name of baseline points and low-water inserts Latitude & Longitude — All points along the boundary are described by geographical coordinates in latitude and longitude expressed in the reference system SWEREF 99 partly in degrees and decimal minutes as stated in the law and partly in decimal degrees. Point type — The following point types exist: • point on the low-water line along the normal baseline (LP); • end point at right base line, baseline point (BP); • segmented point on a straight geodetic line between two baseline points (MP), and • point on low-water lakes located outside a baseline (LS). Type of baseline — The type of baseline (right/normal) starting at the point. Source — Act (2017:1272) on Sweden’s maritime territory and zones. Unique ID — A unique ID added by the Swedish Maritime Administration.

The following attributes are available in the line shape file: Sub-strength — Sub-section for straight baseline. Source — Act (2017:1272) on Sweden’s maritime territory and zones.

description: NOTE: The original data set named WATERWELLS_DNR_WATER_IN_100217.SHP was provided to Indiana Geological Survey personnel on February 17, 2010, personnel from the Indiana Department of Natural Resources, Division of Water, Resource Assessment Section. NOTE: An updated data set named WATERWELLS_DNR_WATER_IN_120312.SHP was provided to Indiana Geological Survey personnel on March 15, 2012, by Mr. Michael P. Martin, GIS Coordinator, Indiana Department of Natural Resources, Division of Outdoor Recreation. NOTE: An updated data set named WATERWELLS_DNR_WATER_IN_130530.SHP was provided to Indiana Geological Survey personnel on July 23, 2013, by Mr. Michael P. Martin, GIS Coordinator, Indiana Department of Natural Resources, Division of Outdoor Recreation. The following is excerpted from the metadata provided by IDNR for the source shapefile WATERWELLS_DNR_WATER_IN_130530.SHP: "This file is a digital geospatial point feature class of both located water well records (which include UTM coordinates) and unlocated water well records (without UTM coordinates as of 200911). The estimated locations used for the unlocated wells were based on the polygon centroid values for the smallest indicated section, quarter, quarter-quarter, or quarter-quarter-quarter section (as indicated in the database) for over 250,000 water well records and for about 26,000 of the 250,000 water well records the UTM's were obtained from address geocoding using the owners address, a generally more accurate method (see process steps below)."; abstract: NOTE: The original data set named WATERWELLS_DNR_WATER_IN_100217.SHP was provided to Indiana Geological Survey personnel on February 17, 2010, personnel from the Indiana Department of Natural Resources, Division of Water, Resource Assessment Section. NOTE: An updated data set named WATERWELLS_DNR_WATER_IN_120312.SHP was provided to Indiana Geological Survey personnel on March 15, 2012, by Mr. Michael P. Martin, GIS Coordinator, Indiana Department of Natural Resources, Division of Outdoor Recreation. NOTE: An updated data set named WATERWELLS_DNR_WATER_IN_130530.SHP was provided to Indiana Geological Survey personnel on July 23, 2013, by Mr. Michael P. Martin, GIS Coordinator, Indiana Department of Natural Resources, Division of Outdoor Recreation. The following is excerpted from the metadata provided by IDNR for the source shapefile WATERWELLS_DNR_WATER_IN_130530.SHP: "This file is a digital geospatial point feature class of both located water well records (which include UTM coordinates) and unlocated water well records (without UTM coordinates as of 200911). The estimated locations used for the unlocated wells were based on the polygon centroid values for the smallest indicated section, quarter, quarter-quarter, or quarter-quarter-quarter section (as indicated in the database) for over 250,000 water well records and for about 26,000 of the 250,000 water well records the UTM's were obtained from address geocoding using the owners address, a generally more accurate method (see process steps below)."

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

Underwater georeferenced photo-transect survey was conducted on September 23 - 27, 2007 at different sections of the reef flat, reef crest and reef slope in Heron Reef. For this survey a snorkeler or diver swam over the bottom while taking photos of the benthos at a set height using a standard digital camera and towing a surface float GPS which was logging its track every five seconds. A standard digital compact camera was placed in an underwater housing and fitted with a 16 mm lens which provided a 1.0 m x 1.0 m footprint, at 0.5 m height above the benthos. Horizontal distance between photos was estimated by three fin kicks of the survey diver/snorkeler, which corresponded to a surface distance of approximately 2.0 - 4.0 m. The GPS was placed in a dry-bag and logged its position as it floated at the surface while being towed by the photographer. A total of 3,586 benthic photos were taken. A floating GPS setup connected to the swimmer/diver by a line enabled recording of coordinates of each benthic. Approximation of coordinates of each benthic photo was done based on the photo timestamp and GPS coordinate time stamp, using GPS Photo Link Software (www.geospatialexperts.com). Coordinates of each photo were interpolated by finding the gps coordinates that were logged at a set time before and after the photo was captured. Benthic or substrate cover data was derived from each photo by randomly placing 24 points over each image using the Coral Point Count excel program (Kohler and Gill, 2006). Each point was then assigned to 1 out of 80 cover types, which represented the benthic feature beneath it. Benthic cover composition summary of each photo scores was generated automatically using CPCE program. The resulting benthic cover data of each photo was linked to gps coordinates, saved as an ArcMap point shapefile, and projected to Universal Transverse Mercator WGS84 Zone 56 South.

The dataset contains the point locations of South Africa Social Security Agency (SASSA) pay points. The dataset is a third party entity published by the South African National Treasury (NT) through the NT's Vulekamali Data Portal (https://geo.vulekamali.gov.za/#category-2). Vulekamali is an easily accessible online data portal that was developed by NT in conjunction with Imali Yethu to promote budget transparency and public participation.

The physical location of the SASSA pay points are deemed as a service point and form part of the service point consortium that includes clinics, schools, post offices and police stations. The South African constitution mandates national, provincial and local governments to provide accessible services to the public through these service points. SASSA paypointss offer eligible South Africans social security services in the form of various grants.

The data was originally accessed and downloaded as a spreadsheet on 01 November 2020 by SAEON. The spreadsheet was then modified into a tidy table, alphabetically arranging the SASSA pay point locations by name in ascending order. This tidy dataset, containing the centroids (latitude and longitude coordinates) of the pay points was then used to create a shapefile of the SASSA pay point locations.

The Geographic Attribute File is a dataset that contains census geographic information at the Enumeration Area level for all of Canada for the 1976 census. Each record includes geographic coordinates, population and dwelling counts, land area, names, unique identifiers, and geographic codes for linkages with other census boundaries.

The original dataset is available from Statistics Canada as a text file (.txt). For viewing in Scholars GeoPortal, the dataset was converted from this original format into a Shapefile format using the point coordinates available for each record. Each point is the population centre of an Enumeration Area.

The original data, and other supporting files and documentation, are available as additional downloads from Scholars GeoPortal.