USGS is assessing the feasibility of map projections and grid systems for lunar surface operations. We propose developing a new Lunar Transverse Mercator (LTM), the Lunar Polar Stereographic (LPS), and the Lunar Grid Reference Systems (LGRS). We have also designed additional grids designed to NASA requirements for astronaut navigation, referred to as LGRS in Artemis Condensed Coordinates (ACC), but this is not released here. LTM, LPS, and LGRS are similar in design and use to the Universal Transverse Mercator (UTM), Universal Polar Stereographic (LPS), and Military Grid Reference System (MGRS), but adhere to NASA requirements. LGRS ACC format is similar in design and structure to historic Army Mapping Service Apollo orthotopophoto charts for navigation. The Lunar Transverse Mercator (LTM) projection system is a globalized set of lunar map projections that divides the Moon into zones to provide a uniform coordinate system for accurate spatial representation. It uses a transverse Mercator projection, which maps the Moon into 45 transverse Mercator strips, each 8°, longitude, wide. These transverse Mercator strips are subdivided at the lunar equator for a total of 90 zones. Forty-five in the northern hemisphere and forty-five in the south. LTM specifies a topocentric, rectangular, coordinate system (easting and northing coordinates) for spatial referencing. This projection is commonly used in GIS and surveying for its ability to represent large areas with high positional accuracy while maintaining consistent scale. The Lunar Polar Stereographic (LPS) projection system contains projection specifications for the Moon’s polar regions. It uses a polar stereographic projection, which maps the polar regions onto an azimuthal plane. The LPS system contains 2 zones, each zone is located at the northern and southern poles and is referred to as the LPS northern or LPS southern zone. LPS, like is equatorial counterpart LTM, specifies a topocentric, rectangular, coordinate system (easting and northing coordinates) for spatial referencing. This projection is commonly used in GIS and surveying for its ability to represent large polar areas with high positional accuracy, while maintaining consistent scale across the map region. LGRS is a globalized grid system for lunar navigation supported by the LTM and LPS projections. LGRS provides an alphanumeric grid coordinate structure for both the LTM and LPS systems. This labeling structure is utilized in a similar manner to MGRS. LGRS defines a global area grid based on latitude and longitude and a 25×25 km grid based on LTM and LPS coordinate values. Two implementations of LGRS are used as polar areas require a LPS projection and equatorial areas a transverse Mercator. We describe the difference in the techniques and methods report associated with this data release. Request McClernan et. al. (in-press) for more information. ACC is a method of simplifying LGRS coordinates and is similar in use to the Army Mapping Service Apollo orthotopophoto charts for navigation. These data will be released at a later date. Two versions of the shape files are provided in this data release, PCRS and Display only. See LTM_LPS_LGRS_Shapefiles.zip file. PCRS are limited to a single zone and are projected in either LTM or LPS with topocentric coordinates formatted in Eastings and Northings. Display only shapefiles are formatted in lunar planetocentric latitude and longitude, a Mercator or Equirectangular projection is best for these grids. A description of each grid is provided below: Equatorial (Display Only) Grids: Lunar Transverse Mercator (LTM) Grids: LTM zone borders for each LTM zone Merged LTM zone borders Lunar Polar Stereographic (LPS) Grids: North LPS zone border South LPS zone border Lunar Grid Reference System (LGRS) Grids: Global Areas for North and South LPS zones Merged Global Areas (8°×8° and 8°×10° extended area) for all LTM zones Merged 25km grid for all LTM zones PCRS Shapefiles:` Lunar Transverse Mercator (LTM) Grids: LTM zone borders for each LTM zone Lunar Polar Stereographic (LPS) Grids: North LPS zone border South LPS zone border Lunar Grid Reference System (LGRS) Grids: Global Areas for North and South LPS zones 25km Gird for North and South LPS zones Global Areas (8°×8° and 8°×10° extended area) for each LTM zone 25km grid for each LTM zone The rasters in this data release detail the linear distortions associated with the LTM and LPS system projections. For these products, we utilize the same definitions of distortion as the U.S. State Plane Coordinate System. Scale Factor, k - The scale factor is a ratio that communicates the difference in distances when measured on a map and the distance reported on the reference surface. Symbolically this is the ratio between the maps grid distance and distance on the lunar reference sphere. This value can be precisely calculated and is provided in their defining publication. See Snyder (1987) for derivation of the LPS scale factor. This scale factor is unitless and typically increases from the central scale factor k_0, a projection-defining parameter. For each LPS projection. Request McClernan et. al., (in-press) for more information. Scale Error, (k-1) - Scale-Error, is simply the scale factor differenced from 1. Is a unitless positive or negative value from 0 that is used to express the scale factor’s impact on position values on a map. Distance on the reference surface are expended when (k-1) is positive and contracted when (k-1) is negative. Height Factor, h_F - The Height Factor is used to correct for the difference in distance caused between the lunar surface curvature expressed at different elevations. It is expressed as a ratio between the radius of the lunar reference sphere and elevations measured from the center of the reference sphere. For this work, we utilized a radial distance of 1,737,400 m as recommended by the IAU working group of Rotational Elements (Archinal et. al., 2008). For this calculation, height factor values were derived from a LOLA DEM 118 m v1, Digital Elevation Model (LOLA Science Team, 2021). Combined Factor, C_F – The combined factor is utilized to “Scale-To-Ground” and is used to adjust the distance expressed on the map surface and convert to the position on the actual ground surface. This value is the product of the map scale factor and the height factor, ensuring the positioning measurements can be correctly placed on a map and on the ground. The combined factor is similar to linear distortion in that it is evaluated at the ground, but, as discussed in the next section, differs numerically. Often C_F is scrutinized for map projection optimization. Linear distortion, δ - In keeping with the design definitions of SPCS2022 (Dennis 2023), we refer to scale error when discussing the lunar reference sphere and linear distortion, δ, when discussing the topographic surface. Linear distortion is calculated using C_F simply by subtracting 1. Distances are expended on the topographic surface when δ is positive and compressed when δ is negative. The relevant files associated with the expressed LTM distortion are as follows. The scale factor for the 90 LTM projections: LUNAR_LTM_GLOBAL_PLOT_HEMISPHERES_distortion_K_grid_scale_factor.tif Height Factor for the LTM portion of the Moon: LUNAR_LTM_GLOBAL_PLOT_HEMISPHERES_distortion_EF_elevation_factor.tif Combined Factor in LTM portion of the Moon LUNAR_LTM_GLOBAL_PLOT_HEMISPHERES_distortion_CF_combined_factor.tif The relevant files associated with the expressed LPS distortion are as follows. Lunar North Pole The scale factor for the northern LPS zone: LUNAR_LGRS_NP_PLOT_LPS_K_grid_scale_factor.tif Height Factor for the north pole of the Moon: LUNAR_LGRS_NP_PLOT_LPS_EF_elevation_factor.tif Combined Factor for northern LPS zone: LUNAR_LGRS_NP_PLOT_LPS_CF_combined_factor.tif Lunar South Pole Scale factor for the northern LPS zone: LUNAR_LGRS_SP_PLOT_LPS_K_grid_scale_factor.tif Height Factor for the south pole of the Moon: LUNAR_LGRS_SP_PLOT_LPS_EF_elevation_factor.tif Combined Factor for northern LPS zone: LUNAR_LGRS_SP_PLOT_LPS_CF_combined_factor.tif For GIS utilization of grid shapefiles projected in Lunar Latitude and Longitude, referred to as “Display Only”, please utilize a registered lunar geographic coordinate system (GCS) such as IAU_2015:30100 or ESRI:104903. LTM, LPS, and LGRS PCRS shapefiles utilize either a custom transverse Mercator or polar Stereographic projection. For PCRS grids the LTM and LPS projections are recommended for all LTM, LPS, and LGRS grid sizes. See McClernan et. al. (in-press) for such projections. Raster data was calculated using planetocentric latitude and longitude. A LTM and LPS projection or a registered lunar GCS may be utilized to display this data. Note: All data, shapefiles and rasters, require a specific projection and datum. The projection is recommended as LTM and LPS or, when needed, IAU_2015:30100 or ESRI:104903. The datum utilized must be the Jet Propulsion Laboratory (JPL) Development Ephemeris (DE) 421 in the Mean Earth (ME) Principal Axis Orientation as recommended by the International Astronomy Union (IAU) (Archinal et. al., 2008).

Download high-quality, up-to-date shapefile boundaries (SHP, projection system SRID 4326). Our Shapefile Database offers comprehensive boundary data for spatial analysis, including administrative areas and geographic boundaries. This dataset contains accurate and up-to-date information on all administrative divisions, zip codes, cities, and geographic boundaries, making it an invaluable resource for various applications such as geographic analysis, map and visualization, reporting and business intelligence (BI), master data management, logistics and supply chain management, and sales and marketing. Our location data packages are available in various formats, including Shapefile, GeoJSON, KML, ASC, DAT, CSV, and GML, optimized for seamless integration with popular systems like Esri ArcGIS, Snowflake, QGIS, and more. Companies choose our location databases for their enterprise-grade service, reduction in integration time and cost by 30%, and weekly updates to ensure the highest quality.

The California State Places Boundary data.

This dataset offers high-resolution boundary definitions, which allow users to analyze and visualize California’s state limits within mapping and spatial analysis projects.

The shapefile is part of a ZIP archive containing multiple related files that together define and support the boundary data. These files include:

.shp (Shape): This is the core file containing the vector data for California’s Places boundaries, representing the geographic location and geometry of the state outline.

.shx (Shape Index): A companion index file for the .shp file, allowing for quick spatial queries and efficient data access.

.dbf (Attribute Table): A database file that stores attribute data linked to the geographic features in the .shp file, such as area identifiers or classification codes, in a tabular format compatible with database applications.

.prj (Projection): This file contains projection information, specifying the coordinate system and map projection used for the data, essential for aligning it accurately on maps.

.cpg (Code Page): This optional file indicates the character encoding for the attribute data in the .dbf file, which is useful for ensuring accurate text representation in various software.

.sbn and .sbx (Spatial Index): These files serve as a spatial index for the shapefile, allowing for faster processing of spatial queries, especially for larger datasets.

.xml (Metadata): A metadata file in XML format, often following FGDC or ISO standards, detailing the dataset’s origin, structure, and usage guidelines, providing essential information about data provenance and quality.

The Northern Circumpolar Soil Carbon Database version 2 (NCSCDv2) is a geospatial database created for the purpose of quantifying storage of organic carbon in soils of the northern circumpolar permafrost region down to a depth of 300 cm. The NCSCDv2 is based on polygons from different regional soils maps homogenized to the U.S. Soil Taxonomy. The NCSCDv2 contains information on fractions of coverage of different soil types (following U.S. Soil Taxonomy nomenclature) as well as estimated storage of soil organic carbon (kg/m2) between 0-30 cm, 0-100 cm, 100-200 cm and 200-300 cm depth. The database was compiled by combining and homogenizing several regional/national soil maps. To calculate storage of soil organic carbon, these soil maps have been linked to field-data on soil organic carbon storage from sites with circumpolar coverage.

More information on database processing and properties can be found in the product guide.

The data is stored as ESRI shapefiles with associated attribute table databases. There are separate zipped data-folders with: (1) a merged circumpolar dataset in the Lambert Azimuthal Equal Area (LAEA) projection, (2) a merged circumpolar dataset geographic latitude/longitude coordinates (WGS84), (3) all regions in separate shape-files, in LAEA projection and (4) all regions in separate shape-files with geographic latitude/longitude coordinates (WGS84).

Citation

In order to use these data, you must cite this data set with the following citation:

Hugelius G, Bockheim JG, Camill, P, Elberling B, Grosse G, Harden JW, Johnson K, Jorgenson T, Koven C, Kuhry P, Michaelson G, Mishra U, Palmtag J, Ping C-L, O’Donnell J, Schirrmeister L, Schuur EAG, Sheng Y, Smith LC, Strauss J, Yu Z. (2013) A new dataset for estimating organic carbon storage to 3m depth in soils of the northern circumpolar permafrost region. Earth System Science Data, 5, 393–402, doi:10.5194/essd-5-393-2013.

**THIS NEWER 2016 DIGITAL MAP REPLACES THE OLDER 2014 VERSION OF THE GRI GATE Geomorphological-GIS data. The Unpublished Digital Pre-Hurricane Sandy Geomorphological-GIS Map of the Gateway National Recreation Area: Sandy Hook, Jamaica Bay and Staten Island Units, New Jersey and New York is composed of GIS data layers and GIS tables in a 10.1 file geodatabase (gate_geomorphology.gdb), a 10.1 ArcMap (.MXD) map document (gate_geomorphology.mxd), individual 10.1 layer (.LYR) files for each GIS data layer, an ancillary map information (.PDF) document (gate_geomorphology.pdf) which contains source map unit descriptions, as well as other source map text, figures and tables, metadata in FGDC text (.TXT) and FAQ (.HTML) formats, and a GIS readme file (gate_gis_readme.pdf). Please read the gate_gis_readme.pdf for information pertaining to the proper extraction of the file geodatabase and other map files. To request GIS data in ESRI 10.1 shapefile format contact Stephanie O’Meara (stephanie.omeara@colostate.edu; see contact information below). The data is also available as a 2.2 KMZ/KML file for use in Google Earth, however, this format version of the map is limited in data layers presented and in access to GRI ancillary table information. Google Earth software is available for free at: http://www.google.com/earth/index.html. Users are encouraged to only use the Google Earth data for basic visualization, and to use the GIS data for any type of data analysis or investigation. The data were completed as a component of the Geologic Resources Inventory (GRI) program, a National Park Service (NPS) Inventory and Monitoring (I&M) Division funded program that is administered by the NPS Geologic Resources Division (GRD). Source geologic maps and data used to complete this GRI digital dataset were provided by the following: Rutgers University Institute of Marine and Coastal Sciences. Detailed information concerning the sources used and their contribution the GRI product are listed in the Source Citation section(s) of this metadata record (gate_metadata_faq.html; available at http://nrdata.nps.gov/geology/gri_data/gis/gate/gate_pre-sandy_metadata_faq.html). Users of this data are cautioned about the locational accuracy of features within this dataset. Based on the source map scale of 1:6,000 and United States National Map Accuracy Standards features are within (horizontally) 5.08 meters or 16.67 feet of their actual location as presented by this dataset. Users of this data should thus not assume the location of features is exactly where they are portrayed in Google Earth, ArcGIS or other software used to display this dataset. All GIS and ancillary tables were produced as per the NPS GRI Geology-GIS Geodatabase Data Model v. 2.3. (available at: http://science.nature.nps.gov/im/inventory/geology/GeologyGISDataModel.cfm). The GIS data projection is NAD83, UTM Zone 18N, however, for the KML/KMZ format the data is projected upon export to WGS84 Geographic, the native coordinate system used by Google Earth. The data is within the area of interest of Gateway National Recreation Area.

This data set provides a grid of quads and projection information to be used for rover operations and the informal geographic naming convention for the regional geography of Oxia Planum. Both subject to update prior to the landed mission.Contents This data set contains 4 shapefiles and 1 zipped folder.OxiaPlanum_GeographicFeatures_2021_08_26. Point shapefile with the names of geographic features last updated at the date indicatedOxiaPlanum_GeographicRegions_2021_08_26. Polygon shapefile with the outlines of geographic regions fitted to the master quad grid and last updated at the date indicated.OxiaPlanum_QuadGrid_1km. Polygon shapefile of 1km quad that will be used for ExoMars rover missionOxiaPlanum_Origin_clong_335_45E_18_20N. The center point of the Oxia Planum as defined by the Rover Operations and Control center and origin point used for the Quad gridCRS_PRJ_Equirectangular_OxiaPlanum_Mars2000.zip. Zip folder containing the projection information use for all the data associated with this study. These are saved in the ESRI projection (.prj) and well know text formal (.wkt)Guide to individual filesFile name (example) Description OxiaPlanum_QuadGrid_1km.cpg Text display information OxiaPlanum_QuadGrid_1km.dbf Database file OxiaPlanum_QuadGrid_1km.prj Projection information OxiaPlanum_QuadGrid_1km.sbx Spatial index file OxiaPlanum_QuadGrid_1km.shp Shape file data <-Open this data in GiS with the other supporting files in the same directoryOxiaPlanum_QuadGrid_1km.shp.xml Symbolisation information OxiaPlanum_QuadGrid_1km.shx Geoprocessing history These data are provided with the following projection:Equirectangular_Mars_Oxia_Planum, Projection = Equidistant_Cylindrical, Datum = D_Mars_2000 Spheroid, Central meridian = 335.45Quad grid and contoursThe quad grid was created using the ArcPro 2.7 Grid Index Features Tool (Esri, 2021). The grid is a 121 × 120 array of 1000 m × 1000 m quads labelled ‘A1’ in the South West to ‘DP120’ in the North East. The grid covers the entire CTX mosaic and the lower left corner of quad BD50 coincides with the centre of the ROCC projection system at 335.45°E 18.20°N. Topographic contours were created at 25 m intervals from a CTX DEM down sampled to 100 m/pixel, with contours shorter than 1500 m in length were removed. Contours were smoothed using the PAEK algorithm at a tolerance of 200 m (USGS & MRCTR GIS Lab, 2018).Geographic regions A common geographical division and naming system for the Oxia Planum region is needed to allow ExoMars team members to communicate efficiently. Identifying and naming geographical locations and zones provides a spatial context for detailed observations, strategic planning and operations, and hypotheses testing. Differentiating geographic regionsWe divide Oxia Planum into 30 regions (Figure 2 and Table 3 from Fawdon et al 2021). This system of regions is a formalisation of the geographic differentiation demanded by discussions since the initial suggestion of Oxia Planum as a landing site in 2014 (ESA & The ExoMars 2018 Landing Site Selection Working Group (LSSWG), 2014) Each region is defined by a combination of topographic and or albedo changes in the HRSC and CTX data and that have needed to be talked about. Regions are smaller closer to the center of the landing site or where topography and albedo are more variable. This reflects the need to increase the fidelity of discussion where the rover is more likely to land or there are likely to have been more active geomorphic processes. As such these regions capture features pertaining to hypotheses about the paleo-environments being developed by the RSOWG and provide a natural framework to explore Oxia Planum. Naming geographic regionsThe regions were named in three ways: a number, a unique identifier, and a descriptive term. Unique identifiers were drawn from a list of Roman imperial and senatorial provinces at the largest geographic extent of the Roman empire in 117AD. This scheme was chosen because it has geographic and cultural ties throughout Europe and provides an appropriate number and variety of names. The descriptive terms (e.g., Planum, Lacus, etc) are those used in planetary toponomy (IAU, 1979). Names were selected to reflect the geography of the region (e.g., Caledonia has high elevation terrain in the northwest, Aegyptus has a large channel feature). Geographic locations within regions are also named. These names were drawn from a wider list of Roman towns or other relevant geographic locations with suitable, but process-agnostic, descriptive term (e.g., Alexandria Tholus named after the city in the ‘Aegyptus’ imperial province). These conventions have the capacity to expand this list as exploration of Oxia Planum continues.Although IAU recognised features (e.g., Malino crater) have also been included, all other names are informal. Informal naming of local features has been performed by previous Mars Rover mission teams. As has occurred during previous missions, some names will probably be replaced with formal IAU designations as the mission progresses.

GeoJunxion‘s ZIP+4 is a complete dataset based on US postal data consisting of plus 35 millions of polygons​. The dataset is NOT JUST a table of spot data, which can be downloaded as csv or other text file as it happens with other suppliers​. The data can be delivered as shapefile through a single RAW data delivery or through an API​.

The January 2021 USPS data source has significantly changed since the previous delivery. Some States have sizably lower ZIP+4 totals across all counties when compared with previous deliveries due to USPS parcelpoint cleanup, while other States have a significant increase in ZIP+4 totals across all counties due to cleanup and other rezoning. California and North Carolina in particular have several new ZIP5s, contributing to the increase in distinct ZIPs and ZIP+4s​.

GeoJunxion‘s ZIP+4 data can be used as an additional layer on an existing map to run customer or other analysis, e.g. who is my customer who not, what is the density of my customer base in a certain ZIP+4 etc.

Information can be put into visual context, due to the polygons, which is good for complex overviews or management decisions. ​CRM data can be enriched with the ZIP+4 to have more detailed customer information​.

Key specifications:

Topologized ZIP polygons​

GeoJunxion ZIP+4 polygons follow USPS postal codes ​

ZIP+4 code polygons: ​

ZIP5 attributes ​

State codes. ​

Overlapping ZIP+4 ​

boundaries for multiple ZIP+4 addresses on one area​

Updated USPS source (January 2021) ​

Distinct ZIP5 codes: 34 731​

Distinct ZIP+4 codes: 35 146 957 ​

The ZIP + 4 polygons are delivered in Esri shapefile format. This format allows the storage of geometry and attribute information for each of the features. ​

The four components for the shapefile data are: ​

.shp – This file stores the geometry of the feature​

.shx –This file stores an index that stores the feature geometry​

.dbf –This file stores attribute information relating to individual features​

.prj –This file stores projection information associated with features​

​Current release version 2021. Earlier versions from previous years available on request.

​

This dataset contains documentation on the 146 global regions used to organize responses to the ArchaeGLOBE land use questionnaire between May 18 and July 31, 2018. The regions were formed from modern administrative regions (Natural Earth 1:50m Admin1 - states and provinces, https://www.naturalearthdata.com/downloads/50m-cultural-vectors/50m-admin-1-states-provinces/). The boundaries of the polygons represent rough geographic areas that serve as analytical units useful in two respects - for the history of land use over the past 10,000 years (a moving target) and for the history of archaeological research. Some consideration was also given to creating regions that were relatively equal in size. The regionalization process went through several rounds of feedback and redrawing before arriving at the 146 regions used in the survey. No bounded regional system could ever truly reflect the complex spatial distribution of archaeological knowledge on past human land use, but operating at a regional scale was necessary to facilitate timely collaboration while achieving global coverage. Map in Google Earth Format: ArchaeGLOBE_Regions_kml.kmz Map in ArcGIS Shapefile Format: ArchaeGLOBE_Regions.zip (multiple files in zip file) The shapefile format is a digital vector file that stores geographic location and associated attribute information. It is actually a collection of several different file types: .shp — shape format: the feature geometry .shx — shape index format: a positional index of the feature geometry .dbf — attribute format: columnar attributes for each shape .prj — projection format: the coordinate system and projection information .sbn and .sbx — a spatial index of the features .shp.xml — geospatial metadata in XML format .cpg — specifies the code page for identifying character encoding Attributes: FID - a unique identifier for every object in a shapefile table (0-145) Shape - the type of object (polygon) World_ID - coded value assigned to each feature according to its division into one of seventeen ‘World Regions’ based on the geographic regions used by the Statistics Division of the United Nations (https://unstats.un.org/unsd/methodology/m49/), with small changes to better reflect archaeological scholarly communities. These large regions provide organizational structure, but are not analytical units for the study. World_RG - text description of each ‘World Region’ Archaeo_ID - unique identifier (1-146) corresponding to the region code used in the ArchaeoGLOBE land use questionnaire and all ArchaeoGLOBE datasets Archaeo_RG - text description of each region Total_Area - the total area, in square kilometers, of each region Land-Area - the total area minus the area of all lakes and reservoirs found within each region (source: https://www.naturalearthdata.com/downloads/10m-physical-vectors/10m-lakes/) PDF of Region Attribute Table: ArchaeoGLOBE Regions Attributes.pdf Excel file of Region Attribute Table: ArchaeoGLOBE Regions Attributes.xls Printed Maps in PDF Format: ArchaeoGLOBE Regions.pdf Documentation of the ArchaeoGLOBE Regional Map: ArchaeoGLOBE Regions README.doc

The California State Boundary data from the US Census Bureau's 2023 MAF/TIGER database provides detailed geographic boundary data designed for use in Geographic Information System applications.

This dataset offers high-resolution boundary definitions, which allow users to analyze and visualize California’s state limits within mapping and spatial analysis projects.

The shapefile is part of a ZIP archive containing multiple related files that together define and support the boundary data. These files include:

.shp (Shape): This is the core file containing the vector data for California’s boundary, representing the geographic location and geometry of the state outline.

.shx (Shape Index): A companion index file for the .shp file, allowing for quick spatial queries and efficient data access.

.dbf (Attribute Table): A database file that stores attribute data linked to the geographic features in the .shp file, such as area identifiers or classification codes, in a tabular format compatible with database applications.

.prj (Projection): This file contains projection information, specifying the coordinate system and map projection used for the data, essential for aligning it accurately on maps.

.cpg (Code Page): This optional file indicates the character encoding for the attribute data in the .dbf file, which is useful for ensuring accurate text representation in various software.

.sbn and .sbx (Spatial Index): These files serve as a spatial index for the shapefile, allowing for faster processing of spatial queries, especially for larger datasets.

.xml (Metadata): A metadata file in XML format, often following FGDC or ISO standards, detailing the dataset’s origin, structure, and usage guidelines, providing essential information about data provenance and quality.

This comprehensive set of files ensures compatibility with most GIS software and allows users to perform a wide range of spatial analyses with detailed information on California’s boundary as defined by the U.S. Census Bureau's 2023 MAF/TIGER database.

Urban areas have a manifold and far-reaching impact on our environment, and the three-dimensional structure is a key aspect for characterizing the urban environment.

This dataset features a map of building height predictions for entire Germany on a 10m grid based on Sentinel-1A/B and Sentinel-2A/B time series. We utilized machine learning regression to extrapolate building height reference information to the entire country. The reference data were obtained from several freely and openly available 3D Building Models originating from official data sources (building footprint: cadaster, building height: airborne laser scanning), and represent the average building height within a radius of 50m relative to each pixel. Building height was only estimated for built-up areas (European Settlement Mask), and building height predictions <2m were set to 0m.

Temporal extent
The acquisition dates of the different data sources vary to some degree:
- Independent variables: Sentinel-2 data are from 2018; Sentinel-1 data are from 2017.
- Dependent variables: the 3D building models are from 2012-2020 depending on data provider.
- Settlement mask: the ESM is based on a mosaic of imagery from 2014-2016.
Considering that net change of building stock is positive in Germany, the building height map is representative for ca. 2015.

Data format
The data come in tiles of 30x30km (see shapefile). The projection is EPSG:3035. The images are compressed GeoTiff files (*.tif). Metadata are located within the Tiff, partly in the FORCE domain. There is a mosaic in GDAL Virtual format (*.vrt), which can readily be opened in most Geographic Information Systems. Building height values are in meters, scaled by 10, i.e. a pixel value of 69 = 6.9m.

Further information
For further information, please see the publication or contact David Frantz (david.frantz@geo.hu-berlin.de).
A web-visualization of this dataset is available here.

Publication
Frantz, D., Schug, F., Okujeni, A., Navacchi, C., Wagner, W., van der Linden, S., & Hostert, P. (2021). National-scale mapping of building height using Sentinel-1 and Sentinel-2 time series. Remote Sensing of Environment, 252, 112128. DOI: https://doi.org/10.1016/j.rse.2020.112128

Acknowledgements
The dataset was generated by FORCE v. 3.1 (paper, code), which is freely available software under the terms of the GNU General Public License v. >= 3. Sentinel imagery were obtained from the European Space Agency and the European Commission. The European Settlement Mask was obtained from the European Commission. 3D building models were obtained from Berlin Partner für Wirtschaft und Technologie GmbH, Freie und Hansestadt Hamburg / Landesbetrieb Geoinformation und Vermessung, Landeshauptstadt Potsdam, Bezirksregierung Köln / Geobasis NRW, and Kompetenzzentrum Geodateninfrastruktur Thüringen. This dataset was partly produced on EODC - we thank Clement Atzberger for supporting the generation of this dataset by sharing disc space on EODC.

Funding
This dataset was produced with funding from the European Research Council (ERC) under the European Union's Horizon 2020 research and innovation programme (MAT_STOCKS, grant agreement No 741950).

USGS is assessing the feasibility of map projections and grid systems for lunar surface operations. We propose developing a new Lunar Transverse Mercator (LTM), the Lunar Polar Stereographic (LPS), and the Lunar Grid Reference Systems (LGRS). We have also designed additional grids designed to NASA requirements for astronaut navigation, referred to as LGRS in Artemis Condensed Coordinates (ACC). This data release includes LGRS grids finer than 25km (1km, 100m, and 10m) in ACC format. LTM, LPS, and LGRS grids are not released here but may be acceded from https://doi.org/10.5066/P13YPWQD. LTM, LPS, and LGRS are similar in design and use to the Universal Transverse Mercator (UTM), Universal Polar Stereographic (LPS), and Military Grid Reference System (MGRS), but adhere to NASA requirements. LGRS ACC format is similar in design and structure to historic Army Mapping Service Apollo orthotopophoto charts for navigation. The Lunar Transverse Mercator (LTM) projection system is a globalized set of lunar map projections that divides the Moon into zones to provide a uniform coordinate system for accurate spatial representation. It uses a Transverse Mercator projection, which maps the Moon into 45 transverse Mercator strips, each 8°, longitude, wide. These Transverse Mercator strips are subdivided at the lunar equator for a total of 90 zones. Forty-five in the northern hemisphere and forty-five in the south. LTM specifies a topocentric, rectangular, coordinate system (easting and northing coordinates) for spatial referencing. This projection is commonly used in GIS and surveying for its ability to represent large areas with high positional accuracy while maintaining consistent scale. The Lunar Polar Stereographic (LPS) projection system contains projection specifications for the Moon’s polar regions. It uses a polar stereographic projection, which maps the polar regions onto an azimuthal plane. The LPS system contains 2 zones, each zone is located at the northern and southern poles and is referred to as the LPS northern or LPS southern zone. LPS, like its equatorial counterpart LTM, specifies a topocentric, rectangular, coordinate system (easting and northing coordinates) for spatial referencing. This projection is commonly used in GIS and surveying for its ability to represent large polar areas with high positional accuracy while maintaining consistent scale across the map region. LGRS is a globalized grid system for lunar navigation supported by the LTM and LPS projections. LGRS provides an alphanumeric grid coordinate structure for both the LTM and LPS systems. This labeling structure is utilized similarly to MGRS. LGRS defines a global area grid based on latitude and longitude and a 25×25 km grid based on LTM and LPS coordinate values. Two implementations of LGRS are used as polar areas require an LPS projection and equatorial areas a Transverse Mercator. We describe the differences in the techniques and methods reported in this data release. Request McClernan et. al. (in-press) for more information. ACC is a method of simplifying LGRS coordinates and is similar in use to the Army Mapping Service Apollo orthotopophoto charts for navigation. These grids are designed to condense a full LGRS coordinate to a relative coordinate of 6 characters in length. LGRS in ACC format is completed by imposing a 1km grid within the LGRS 25km grid, then truncating the grid precision to 10m. To me the character limit, a coordinate is reported as a relative value to the lower-left corner of the 25km LGRS zone without the zone information; However, zone information can be reported. As implemented, and 25km^2 area on the lunar surface will have a set of a unique set of ACC coordinates to report locations The shape files provided in this data release are projected in the LTM or LPS PCRSs and must utilize these projections to be dimensioned correctly. LGRS ACC Grids Files and Resolution: LGRS ACC Grids in LPS portion: Amundsen_Rim 1km Grid Shapefile 100m Grid Shapefile 10m Grid Shapefile Nobile_Rim_2 1km Grid Shapefile 100m Grid Shapefile 10m Grid Shapefile Haworth 1km Grid Shapefile 100m Grid Shapefile 10m Grid Shapefile Faustini_Rim_A 1km Grid Shapefile 100m Grid Shapefile 10m Grid Shapefile de_Gerlache_Rim_2 1km Grid Shapefile 100m Grid Shapefile 10m Grid Shapefile Connecting_Ridge_Extension 1km Grid Shapefile 100m Grid Shapefile 10m Grid Shapefile Connecting_Ridge 1km Grid Shapefile 100m Grid Shapefile 10m Grid Shapefile Nobile_Rim_1 1km Grid Shapefile 100m Grid Shapefile 10m Grid Shapefile Peak_Near_Shackleton 1km Grid Shapefile 100m Grid Shapefile 10m Grid Shapefile de_Gerlache_Rim' 'Leibnitz_Beta_Plateau 1km Grid Shapefile 100m Grid Shapefile 10m Grid Shapefile Malapert_Massif 1km Grid Shapefile 100m Grid Shapefile 10m Grid Shapefile de_Gerlache-Kocher_Massif 1km Grid Shapefile 100m Grid Shapefile 10m Grid Shapefile LGRS ACC Grids in LTM portion: Apollo_11 1km Grid Shapefile 100m Grid Shapefile 10m Grid Shapefile Apollo_12 1km Grid Shapefile 100m Grid Shapefile 10m Grid Shapefile Apollo_14 1km Grid Shapefile 100m Grid Shapefile 10m Grid Shapefile Apollo_15 1km Grid Shapefile 100m Grid Shapefile 10m Grid Shapefile Apollo_16 1km Grid Shapefile 100m Grid Shapefile 10m Grid Shapefile Apollo_17 1km Grid Shapefile 100m Grid Shapefile 10m Grid Shapefile LTM, LPS, and LGRS PCRS shapefiles utilize either a custom transverse Mercator or polar Stereographic projection. For PCRS grids the LTM and LPS projections are recommended for all LTM, LPS, and LGRS grid sizes. See McClernan et. al. (in-press) for such projections. For GIS utilization of grid shapefiles projected in Lunar Latitude and Longitude should utilize a registered lunar geographic coordinate system (GCS) such as IAU_2015:30100 or ESRI:104903. This only applies to grids that cross multiple LTM zones. Note: All data, shapefiles require a specific projection and datum. The projection is recommended as LTM and LPS or, when needed, IAU_2015:30100 or ESRI:104903. The datum utilized must be the Jet Propulsion Laboratory (JPL) Development Ephemeris (DE) 421 in the Mean Earth (ME) Principal Axis Orientation as recommended by the International Astronomy Union (IAU) (Archinal et. al., 2008).

This data is a mosaic of CTX DEM and ORI’s covering the ExoMars rover landing site in Oxia Planum. This data is a basemap for Oxia Planum and will act as a georeferencing base layer for future High resolution datasets of the rover landing site.ContentsThis data set contains 4 directories:03_a Sets of elevation contours at 100 m and 25 m spacing made from the DEM and smoothed for use in map publications.03_b Mosaic of orthorectified CTX images that accompany the DEM. These data are provided in an equirectangular projection centered at 335.45°E 03_c Hillshade model of the CTX DEM mosaic. These data are provided to help assess the variability and quality of the DEM. These data are provided in an equirectangular projection centered at 335.45°E03_d CTX DEM mosaic. These data are provided in an equirectangular projection centered at 335.45°EGuide to individual files03_a_CTX_DEM_contoursNaming convention: CTX_OXIA_DEM = data from which the contours where created, _cont = contour data, _m = vertical separation of the contours (25 or 100.)File name (example) Description CTX_OXIA_DEM_cont_100m.cpg CTX_OXIA_DEM_cont_100m.dbf CTX_OXIA_DEM_cont_100m.prj Projection information CTX_OXIA_DEM_cont_100m.sbx CTX_OXIA_DEM_cont_100m.shp <- Shape file data Open this data in GiS with the other supporting files in the same directoryCTX_OXIA_DEM_cont_100m.shp.xml Geoprocessing history CTX_OXIA_DEM_cont_100m.shx 03_b_CTX_ORINaming convention: CTX = Instrument, OXIA = Location, ORI = Orthorectified image, 6m = pixel sizeFile name Description CTX_OXIA_ORI_6m.tfw World file <- Open this data in GiS with the other supporting files in the same directoryCTX_OXIA_ORI_6m.tif Image data CTX_OXIA_ORI_6m.tif.aux.xml Auxiliary symbology statistics CTX_OXIA_ORI_6m.tif.ovr Image overviews CTX_OXIA_ORI_6m.tif.xml Geoprocessing history These data are provided with the following projection: Equirectangular_Mars_Oxia_Planum, Projections = Equidistant_Cylindrical, Datum = D_Mars_2000 Spheroid, Central meridian = 335.4503_c_CTX_DEM_hsNaming convention: CTX = Instrument, OXIA = Location, DEM = Digital Elevation Model, 20m = Pixel Size, _hs = hill shade model (sun potion 315°, azimuth 45°)File name Description CTX_OXIA_DEM_20m_hs.tfw World file <- Open this data in GiS with the other supporting files in the same directoryCTX_OXIA_DEM_20m_hs.tif Image data CTX_OXIA_DEM_20m_hs.tif.aux.xml Auxiliary symbology statistics CTX_OXIA_DEM_20m_hs.ovr Image overviews CTX_OXIA_ DEM_20m_hs.tif.xml Geoprocessing history 03_d_CTX_DEMNaming convention: CTX = Instrument, OXIA = Location, DEM = Digital Elevation Model, 20m = Pixel SizeFile name Description CTX_OXIA_DEM_20m.tfw World file <- Open this data in GiS with the other supporting files in the same directoryCTX_OXIA_DEM_20m.tif Image data CTX_OXIA_DEM_20m.tif.aux.xml Auxiliary symbology statistics CTX_OXIA_DEM_20m.ovr Image overviews These data are provided with the following projection: Equirectangular_Mars_Oxia_Planum, Projections = Equidistant_Cylindrical, Datum = D_Mars_2000 Spheroid, Central meridian = 335.45Digital elevation models Digital elevation models (DEMs) were produced from CTX stereo images using the USGS Integrated Software for Imagers and Spectrometers (ISIS) software and the BAE photogrammetric package SOCET SET according to the method of Kirk et al. (2008). We selected 6 CTX image pairs to maximise coverage of the canyon. Tie points were automatically populated in SOCET SET between each image pair. In a departure from previous methods, we ran bundle adjustments on adjacent stereo pairs, removing erroneous tie points until the remaining points had an RMS pixel matching error of ≤ 0.6 pixels. This approach resulted in improved coregistration between stereo pairs, and minimal topographic artefacts across stereo pair boundaries. Each resultant DEM was tied vertically to Mars Orbital Laser Altimeter (MOLA; Zuber et al., 1992) topography and exported with a horizontal post spacing of 20 m/pixel. We then exported orthorectified images from SOCET SET at a resolution of 6 m/pixel. The orthorectified images (ORI) and DEMs were then post-processed in ISIS, mosaicked in the software ENvironment for Visualising Images (ENVI), provided by Harris Geospatial, before manual georeferencing in ArcGIS. Finally, the georeferenced image mosaic was blended in Adobe Photoshop to remove seamlines using the Avenza Geographic Imager extension, which retains geospatial information in the blended product.The output from SocetSet® are 18 – 20 m/pix DEM resolving topography of ~50 – 60 m features and 12 orthorectified CTX images at 6 m/pix. The Expected Vertical Precision (EVP) in each CTX DEM can be estimated based on viewing geometry and pixel scale (Randolph L. Kirk et al., 2003, 2008) e.g. EVP = Δp IFOV / (parallax/height). Where: Δp is the RMS stereo matching error in pixel units, assumed to be 0.2 pixels (Cook et al., 1996) and confirmed with matching software for several other planetary image data sets (Howington-Kraus et al., 2002; R. L. Kirk et al., 1999). The pixel matching error is influenced by signal-to-noise ratio, scene contrast and differences in illumination between the images. Pattern noise can also be introduced by the automatic terrain extraction algorithm, especially in areas of low correlation. These can be identified as patches of ‘triangles’ in the hillshade model (e.g., smooth, low contrast slopes and along shadows). IFOV is the instantaneous field of view of the image (pixel size in metres). If the paired images have different IFOV the RMS values is used e.g. IFOV = √(pixel scale image 1 + pixel scale image 2). The parallax/height ratio, calculated from the three-dimensional intersection geometry, reduces to tan(e) for an image with emission angle ‘e’ paired with a nadir image, e.g., parallax/height = tan(e) where e = |emission angle 1 − emission angle 2|.GeoreferencingMars Express High Resolution Stereo Camera (HRSC; Gwinner et al., 2016) MC11- mosaic (Kersten et al., 2018) has been used as the base control mosaic (tile HMC_11W24_co5ps.tif http://hrscteam.dlr.de/HMC30/).. This data is controlled to the Mars Orbital Laser Altimeter (MOLA; Smith et al., 2001) data the most accurate elevation data for Mars.Registration of the CTX DEM mosaic to the HRSC mosaic used manual tie points between the CTX ORI and HRSC mosaic and applying these tie points to the DEM mosaic. Manual tie points were used because automatic methods gave unsatisfactory results. The CTX mosaic data was rectified using the spline transformation. which optimizes for local accuracy but not global accuracy (Esri, 2020). This method provided good results for images with a range of viewing angles and accounts well for local adjustments needed for abrupt elevation changes.Topographic contoursTopographic contours were created at 25 m intervals from a CTX DEM down sampled to 100 m/pix, and contours shorter than 1500 m were removed and the lines smoothed using the PAEK algorithm at a tolerance of 200 m (USGS & MRCTR GIS Lab, 2018).

Download high-quality, up-to-date United Arab Emirates shapefile boundaries (SHP, projection system SRID 4326). Our United Arab Emirates Shapefile Database offers comprehensive boundary data for spatial analysis, including administrative areas and geographic boundaries. This dataset contains accurate and up-to-date information on all administrative divisions, zip codes, cities, and geographic boundaries, making it an invaluable resource for various applications such as geographic analysis, map and visualization, reporting and business intelligence (BI), master data management, logistics and supply chain management, and sales and marketing. Our location data packages are available in various formats, including Shapefile, GeoJSON, KML, ASC, DAT, CSV, and GML, optimized for seamless integration with popular systems like Esri ArcGIS, Snowflake, QGIS, and more. Companies choose our location databases for their enterprise-grade service, reduction in integration time and cost by 30%, and weekly updates to ensure the highest quality.

This dataset provides locations and technical specifications of wind turbines in the United States, almost all of which are utility-scale. Utility-scale turbines are ones that generate power and feed it into the grid, supplying a utility with energy. They are usually much larger than turbines that would feed a homeowner or business.

The data formats downloadable from the Minnesota Geospatial Commons contain just the Minnesota turbines. Data, maps and services accessed from the USWTDB website provide nationwide turbines.

The regularly updated database has wind turbine records that have been collected, digitized, and locationally verified. Turbine data were gathered from the Federal Aviation Administration's (FAA) Digital Obstacle File (DOF) and Obstruction Evaluation Airport Airspace Analysis (OE-AAA), the American Wind Energy Association (AWEA), Lawrence Berkeley National Laboratory (LBNL), and the United States Geological Survey (USGS), and were merged and collapsed into a single data set.

Verification of the turbine positions was done by visual interpretation using high-resolution aerial imagery in Esri ArcGIS Desktop. A locational error of plus or minus 10 meters for turbine locations was tolerated. Technical specifications for turbines were assigned based on the wind turbine make and models as provided by manufacturers and project developers directly, and via FAA datasets, information on the wind project developer or turbine manufacturer websites, or other online sources. Some facility and turbine information on make and model did not exist or was difficult to obtain. Thus, uncertainty may exist for certain turbine specifications. Similarly, some turbines were not yet built, not built at all, or for other reasons cannot be verified visually. Location and turbine specifications data quality are rated and a confidence is recorded for both. None of the data are field verified.

The U.S. Wind Turbine Database website provides the national data in many different formats: shapefile, CSV, GeoJSON, web services (cached and dynamic), API, and web viewer. See: https://eerscmap.usgs.gov/uswtdb/

The web viewer provides many options to search; filter by attribute, date and location; and customize the map display. For details and screenshots of these options, see: https://eerscmap.usgs.gov/uswtdb/help/

------------
This metadata record was adapted by the Minnesota Geospatial Information Office (MnGeo) from the national version of the metadata. It describes the Minnesota extract of the shapefile data that has been projected from geographic to UTM coordinates and converted to Esri file geodatabase (fgdb) format. There may be more recent updates available on the national website. Accessing the data via the national web services or API will always provide the most recent data.

The TIGER/Line shapefilez and related database files (.dbf) are an extract of selected geographic and cartographic information from the U.S. Census Bureau's Master Address File / Topologically Integrated Geographic Encoding and Referencing (MAF/TIGER) Database (MTDB). The MTDB represents a seamless national file with no overlaps or gaps between parts, however, each TIGER/Line shapefile is designed to stand alone as an independent data set, or they can be combined to cover the entire nation.

The TIGER/Line shapefiles include both incorporated places (legal entities) and census designated places or CDPs (statistical entities). An incorporated place is established to provide governmental functions for a concentration of people as opposed to a minor civil division (MCD), which generally is created to provide services or administer an area without regard, necessarily, to population. Places always nest within a state, but may extend across county and county subdivision boundaries. An incorporated place usually is a city, town, village, or borough, but can have other legal descriptions. CDPs are delineated for the decennial census as the statistical counterparts of incorporated places. CDPs are delineated to provide data for settled concentrations of population that are identifiable by name, but are not legally incorporated under the laws of the state in which they are located. The boundaries for CDPs often are defined in partnership with state, local, and/or tribal officials and usually coincide with visible features or the boundary of an adjacent incorporated place or another legal entity. CDP boundaries often change from one decennial census to the next with changes in the settlement pattern and development; a CDP with the same name as in an earlier census does not necessarily have the same boundary. The only population/housing size requirement for CDPs is that they must contain some housing and population.

The boundaries of most incorporated places in this shapefile are as of January 1, 2015, as reported through the Census Bureau's Boundary and Annexation Survey (BAS). The boundaries of all CDPs were delineated as part of the Census Bureau's Participant Statistical Areas Program (PSAP) for the 2010 Census.

📄 Dataset Description This dataset contains selected ecoregion shapefiles related to the Amazon biome, extracted from the official RESOLVE Ecoregions 2017 dataset available through Google Earth Engine (GEE). The original dataset was developed by The Nature Conservancy, the World Wildlife Fund (WWF), and other partners, and provides a scientifically-based global map of terrestrial ecoregions.

The specific ecoregions included here are:

Southwest Amazon Moist Forests

Amazon-Orinoco-Southern Caribbean Mangroves

These shapefiles were exported directly from GEE for the purpose of geospatial analysis in the context of detecting potential archaeological or ecological sites using machine learning.

🔗 Source Dataset name: RESOLVE/ECOREGIONS/2017

Provider: World Wildlife Fund (WWF) and partners

Accessed via: Google Earth Engine Dataset Catalog

Citation: Dinerstein et al. (2017). "An Ecoregion-Based Approach to Protecting Half the Terrestrial Realm." BioScience, 67(6), 534–545.

📦 File Format The dataset is provided in the ESRI Shapefile format and includes:

.shp — main geometry file

.shx — shape index format

.dbf — attribute data

.prj — projection information

Each ecoregion is stored as a FeatureCollection of polygon geometries with associated metadata such as ecoregion name, biome type, realm, and code.

⚠️ Disclaimer This dataset was extracted and re-shared for academic and research purposes only. All original credit goes to the dataset authors and providers. Please cite the source if used in your work.

The Unpublished Digital Geologic-GIS Map of Santa Rosa Island, California is composed of GIS data layers and GIS tables in a 10.1 file geodatabase (sris_geology.gdb), a 10.1 ArcMap (.MXD) map document (sris_geology.mxd), individual 10.1 layer (.LYR) files for each GIS data layer, an ancillary map information (.PDF) document (chis_geology.pdf) which contains source map unit descriptions, as well as other source map text, figures and tables, metadata in FGDC text (.TXT) and FAQ (.HTML) formats, and a GIS readme file (chis_gis_readme.pdf). Please read the chis_gis_readme.pdf for information pertaining to the proper extraction of the file geodatabase and other map files. To request GIS data in ESRI 10.1 shapefile format contact Stephanie O’Meara (stephanie.omeara@colostate.edu; see contact information below). The data is also available as a 2.2 KMZ/KML file for use in Google Earth, however, this format version of the map is limited in data layers presented and in access to GRI ancillary table information. Google Earth software is available for free at: http://www.google.com/earth/index.html. Users are encouraged to only use the Google Earth data for basic visualization, and to use the GIS data for any type of data analysis or investigation. The data were completed as a component of the Geologic Resources Inventory (GRI) program, a National Park Service (NPS) Inventory and Monitoring (I&M) Division funded program that is administered by the NPS Geologic Resources Division (GRD). Source geologic maps and data used to complete this GRI digital dataset were provided by the following: American Association of Petroleum Geologists. Detailed information concerning the sources used and their contribution the GRI product are listed in the Source Citation section(s) of this metadata record (sris_metadata_faq.html; available at http://nrdata.nps.gov/geology/gri_data/gis/chis/sris_metadata_faq.html). Users of this data are cautioned about the locational accuracy of features within this dataset. Based on the source map scale of 1:24,000 and United States National Map Accuracy Standards features are within (horizontally) 12.2 meters or 40 feet of their actual location as presented by this dataset. Users of this data should thus not assume the location of features is exactly where they are portrayed in Google Earth, ArcGIS or other software used to display this dataset. All GIS and ancillary tables were produced as per the NPS GRI Geology-GIS Geodatabase Data Model v. 2.3. (available at: http://science.nature.nps.gov/im/inventory/geology/GeologyGISDataModel.cfm). The GIS data projection is NAD83, UTM Zone 10N, however, for the KML/KMZ format the data is projected upon export to WGS84 Geographic, the native coordinate system used by Google Earth. The data is within the area of interest of Channel Islands National Park.

Impact craters are fundamental in planetary science, providing insights into the geological evolution of planetary surfaces and influencing landing site selection. However, many crater extraction algorithms are either not open-sourced or require complex configurations. To address these issues, we present the Automatic Crater Detection (ACD) Tool, a user-friendly software designed to support scientists, even those without a computational background.Key FeaturesThe ACD Tool utilizes the YOLOv8 deep learning algorithm, enhanced by transfer learning and active learning techniques. This integration enables the detection of craters with a minimum diameter of 10 pixels on terrestrial planets. The tool has undergone rigorous testing on datasets from the Moon, Mars, and Mercury, achieving F1 scores of up to 95%, making it reliable for tasks like surface age estimation and landing site analysis.User Interface and OperationThe interface of the ACD tool is divided into two parts: the left side serves as the input and control panel, while the right side functions as the display area. Users can select among three celestial bodies – Mars, Moon, or Mercury – by clicking on the respective options. The software offers two input modes. In "single image" mode, users directly enter the image paths. In "batch" mode, the program processes all TIFF files within a specified folder. Input images should be GeoTIFF files in Mercator projection to ensure circular shapes for impact craters.The automatic crater detection process begins with a click of the “Start” button.The right-hand viewing interface shows a preview image displaying the crater detection results. In batch mode, the “Previous Image” and “Next Image” buttons allow sequential preview of all images and detection results.Data and OutputInput images should be in GeoTIFF format with Mercator projection centered on the equator to ensure accurate detection.Output results are saved in the specified output path in both shapefile and TXT file formats. The attribute table of the shapefile includes the crater central latitude and longitude (‘Lon’ and ‘Lat’) and the geodesic diameter in meters (‘Dia’). The projection distortion caused by projection has been considered and corrected through computation within the tool. As the craters are extracted in Mercator projection, the corresponding information is provided to better correspond with the images: ‘X_Merc’ and ‘Y_Merc’ for the x and y coordinates in Mercator and ‘D_Merc’ for the distorted diameter measured in the Mercator projection. The confidence score (‘Score’), ranging from 0 to 1, is also provided; higher values indicate greater confidence in the crater detection results. Additionally, a TXT file containing information identical to the shapefile attributes is generated. If an error occurs during the detection process, the names of the erroneous images and the reasons are recorded in an Error.txt file.VersionThe ACD Tool runs on Windows and offers both CPU and GPU versions, allowing users to choose the version that best fits their needs. For faster performance, the GPU version is recommended if a graphics card is available. Otherwise, the CPU version is suitable for systems without a dedicated graphics card.DatasetsOur dataset includes annotated craters on the Moon, Mars, and Mercury. The initial annotations were sourced from publicly available online databases and were further supplemented with manual annotations. For the Moon, LROC WAC images (Speyerer, 2011; Wagner, 2015) and SELENE TC images (Kato et al., 2008) were annotated based on the studies of Robbins (2019) and Wang & Wu (2019), respectively, while LROC NAC images were fully manually annotated. For Mars, crater annotations for the THEMIS-IR mosaic (Edwards et al., 2011) followed the work of Robbins & Hynek (2012), and additional manual annotations were applied to CTX (Malin et al., 2007) and HiRISE (McEwen et al., 2007) images. For Mercury, the MDIS global mosaic (Becker et al., 2009; Hawkins III et al., 2009) underwent complete manual annotation and verification.The dataset includes craters of various sizes and resolutions. On the Moon, the LROC WAC dataset has a resolution of 150 m/pixel, covering 186,302 craters with diameters ranging from 1,000 to 46,692 meters. The LROC NAC dataset, with a resolution of 1.1 m/pixel, includes 34,012 craters with diameters between 7 and 307 meters. The SELENE TC dataset has a resolution of 6.2 m/pixel and includes 54,563 craters with diameters between 120 and 1,949 meters. For Mars, the THEMIS-IR dataset has a resolution of 150 m/pixel and includes 121,517 craters with diameters ranging from 994 to 47,322 meters. The CTX dataset has a resolution of 5 m/pixel and includes 6,678 craters with diameters between 21 and 2,467 meters. The HiRISE dataset, with a resolution of 0.5 to 1 m/pixel, includes 5,978 craters with diameters ranging from 2 to 144 meters. For Mercury, the MDIS dataset has a resolution of 166 m/pixel and includes 17,749 manually annotated craters with diameters ranging from 996 to 26,347 meters.The dataset is organized by body, stored in YOLO annotation format, and located in the respective subfolders within the “Datasets” directory. Each body folder contains “images” and “labels” folders, which store crater images and position annotations, respectively. Within each folder, data is further divided into “train” and “val” subfolders for training and validation.

New Jersey's canals and water raceways have been important for transportation and water power for the last 300 years. They have played a significant role in the economic development of the state. This product contains a Geographic Information System (GIS) ESRI polygon shapefile of the canals and raceways, with selected attributes. It also comes with an associated database file, projection file and metadata. The shapefile and metadata are compressed as a .zip file for download. This data shows locations of current and historic canals and raceways. Where possible, these have been mapped based on site visits or current aerial photographs. The location of some abandoned and filled canals and raceways are approximated from historic maps and photographs and are not guaranteed to be accurate. Some of the mapped canals and raceways are located on private property with no public access. Other canals and raceways allow public access on the canal itself or neighboring pathways, for recreational purposes. The user of this product is responsible for determining if a canal or raceway is open to the public before visiting. This data does not include dewatering canals and ditches with two exceptions, the Berry's Creek Canal and the Old Canal. They were included in this data because they are navigable. Channelized streams and underground aqueducts are not included in this shapefile. The New Jersey Geological Survey is interested in updating this product. Please send information on canals and raceways not shown here to njgsweb@dep.nj.gov. Please include specific site locations and, if possible, an aerial image or map.

The Unpublished Digital Geologic-GIS Map of San Miguel Island, California is composed of GIS data layers and GIS tables in a 10.1 file geodatabase (smis_geology.gdb), a 10.1 ArcMap (.MXD) map document (smis_geology.mxd), individual 10.1 layer (.LYR) files for each GIS data layer, an ancillary map information (.PDF) document (chis_geology.pdf) which contains source map unit descriptions, as well as other source map text, figures and tables, metadata in FGDC text (.TXT) and FAQ (.HTML) formats, and a GIS readme file (chis_gis_readme.pdf). Please read the chis_gis_readme.pdf for information pertaining to the proper extraction of the file geodatabase and other map files. To request GIS data in ESRI 10.1 shapefile format contact Stephanie O’Meara (stephanie.omeara@colostate.edu; see contact information below). The data is also available as a 2.2 KMZ/KML file for use in Google Earth, however, this format version of the map is limited in data layers presented and in access to GRI ancillary table information. Google Earth software is available for free at: http://www.google.com/earth/index.html. Users are encouraged to only use the Google Earth data for basic visualization, and to use the GIS data for any type of data analysis or investigation. The data were completed as a component of the Geologic Resources Inventory (GRI) program, a National Park Service (NPS) Inventory and Monitoring (I&M) Division funded program that is administered by the NPS Geologic Resources Division (GRD). Source geologic maps and data used to complete this GRI digital dataset were provided by the following: American Association of Petroleum Geologists. Detailed information concerning the sources used and their contribution the GRI product are listed in the Source Citation section(s) of this metadata record (smis_metadata_faq.html; available at http://nrdata.nps.gov/geology/gri_data/gis/chis/smis_metadata_faq.html). Users of this data are cautioned about the locational accuracy of features within this dataset. Based on the source map scale of 1:24,000 and United States National Map Accuracy Standards features are within (horizontally) 12.2 meters or 40 feet of their actual location as presented by this dataset. Users of this data should thus not assume the location of features is exactly where they are portrayed in Google Earth, ArcGIS or other software used to display this dataset. All GIS and ancillary tables were produced as per the NPS GRI Geology-GIS Geodatabase Data Model v. 2.3. (available at: http://science.nature.nps.gov/im/inventory/geology/GeologyGISDataModel.cfm). The GIS data projection is NAD83, UTM Zone 10N, however, for the KML/KMZ format the data is projected upon export to WGS84 Geographic, the native coordinate system used by Google Earth. The data is within the area of interest of Channel Islands National Park.