The Residential Schools Locations Dataset in shapefile format contains the locations (latitude and longitude) of Residential Schools and student hostels operated by the federal government in Canada. All the residential schools and hostels that are listed in the Indian Residential School Settlement Agreement are included in this data set, as well as several Industrial schools and residential schools that were not part of the IRRSA. This version of the dataset doesn’t include the five schools under the Newfoundland and Labrador Residential Schools Settlement Agreement. The original school location data was created by the Truth and Reconciliation Commission, and was provided to the researcher (Rosa Orlandini) by the National Centre for Truth and Reconciliation in April 2017. The data set was created by Rosa Orlandini, and builds upon and enhances the previous work of the Truth and Reconcilation Commission, Morgan Hite (creator of the Atlas of Indian Residential Schools in Canada that was produced for the Tk'emlups First Nation and Justice for Day Scholar's Initiative, and Stephanie Pyne (project lead for the Residential Schools Interactive Map). Each individual school location in this dataset is attributed either to RSIM, Morgan Hite, NCTR or Rosa Orlandini. Many schools/hostels had several locations throughout the history of the institution. If the school/hostel moved from its’ original location to another property, then the school is considered to have two unique locations in this data set,the original location and the new location. For example, Lejac Indian Residential School had two locations while it was operating, Stuart Lake and Fraser Lake. If a new school building was constructed on the same property as the original school building, it isn't considered to be a new location, as is the case of Girouard Indian Residential School. When the precise location is known, the coordinates of the main building are provided, and when the precise location of the building isn’t known, an approximate location is provided. For each residential school institution location, the following information is provided: official names, alternative name, dates of operation, religious affiliation, latitude and longitude coordinates, community location, Indigenous community name, contributor (of the location coordinates), school/institution photo (when available), location point precision, type of school (hostel or residential school) and list of references used to determine the location of the main buildings or sites. The geographic coordinate system for this dataset is WGS 1984. The data in shapefile format [IRS_locations.zip] can be viewed and mapped in a Geographic Information System software. Detailed metadata in xml format is available as part of the data in shapefile format. In addition, the field name descriptions (IRS_locfields.csv) and the detailed locations descriptions (IRS_locdescription.csv) should be used alongside the data in shapefile format.

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 .zipThis is a statewide digital version of the Hydrography layer of the published USGS 1:24OOO-scale topographic map series. It was created from DLG files of each scanned 7.5-minute quad map, using custom ARC/INFO software routines which did the following steps: convert from DLG format to coverage format project from UTM to StatePlane map projection rubbersheet map sheet corners to exact computed quad-corner coordinates run semi-automated Edgematching procedure which joins hydrography lines along the quad edges, using distance-offset (maximum of 100 feet) and attribute-match criteria to determine which lines to join. merge the individual quad coverages and dissolve the quad-edge lines Processing was done using Double Precision coordinates and math, with processing tolerance (Fuzzy) of 1 foot.

In the Database/Dataset Section the items CMAJOR and CMINOR represent coded pairs and are documented together. Up to five pairs in the pat and four pairs in the aat may be present. These will be appear in the tables as CMAJOR1 CMINOR1 CMAJOR2 CMINOR2, etc.

The layer has been provided in both shape file and coverage format. In the case of the shape file separate shape files are provided for point, line, and polygon data. In the coverage format the line and polygon data is combined in one coverage. The shape files will be the choice of most users due to speed of drawing issues. Those users desiring to manipulate the original data may want to use the coverage format. All shapefiles have been combined for simplicities sake into one self extracting zip file which expands to about 500 megabytes. However, the value listed in the file size parameter of the metadata represents only the size of the particular shapefile being documented. Also it should be noted that the coverages contain redefined items which of necessity had to be split into separate items or omitted in the shape files because this option isn't available in shapefiles.

This layer documentation is for the Shapefile which includes line features.Contact Information:GIS Support, ODNR GIS ServicesOhio Department of Natural ResourcesReal Estate & Land ManagementReal Estate and Lands Management2045 Morse Rd, Bldg I-2Columbus, OH, 43229Telephone: 614-265-6462Email: gis.support@dnr.ohio.gov

Please note this dataset is the most recent version of the Administrative Boundaries (AB). For previous versions of the AB please go to this url: https://data.gov.au/dataset/ds-dga-b4ad5702-ea2b-4f04-833c-d0229bfd689e/details?q=previous

Geoscape Administrative Boundaries is Australia’s most comprehensive national collection of boundaries, including government, statistical and electoral boundaries. It is built and maintained by Geoscape Australia using authoritative government data. Further information about contributors to Administrative Boundaries is available here.

This dataset comprises seven Geoscape products:

• Localities
• Local Government Areas (LGAs)
• Wards
• Australian Bureau of Statistics (ABS) Boundaries
• Electoral Boundaries
• State Boundaries and
• Town Points

Updated versions of Administrative Boundaries are published on a quarterly basis.

Users have the option to download datasets with feature coordinates referencing either GDA94 or GDA2020 datums.

Notable changes in the May 2025 release

• Victorian Wards have seen almost half of the dataset change now reflecting the boundaries from the 2024 subdivision review. https://www.vec.vic.gov.au/electoral-boundaries/council-reviews/ subdivision-reviews.

  • There have been spatial changes (area) greater than 1 km2 to 66 wards in Victoria.

• One new locality ‘Kenwick Island’ has been added to the local Government area ‘Mackay Regional’ in Queensland.

  • There have been spatial changes(area) greater than 1 km2 to the local government areas 'Burke Shire' and 'Mount Isa City' in Queensland.

• There have been spatial changes(area) greater than 1 km2 to the localities ‘Nicholson’, ‘Lawn Hill’ and ‘Coral Sea’ in Queensland and ‘Calguna’, ‘Israelite Bay’ and ‘Balladonia’ in Western Australia.

• An update to the NT Commonwealth Electoral Boundaries has been applied to reflect the redistribution of the boundaries gazetted on 4 March 2025.

• Geoscape has become aware that the DATE_CREATED and DATE_RETIRED attributes in the commonwealth_electoral_polygon MapInfo TAB tables were incorrectly ordered and did not match the product data model. These attributes have been re-ordered to match the data model for the May 2025 release.

IMPORTANT NOTE: correction of issues with the 22 November 2022 release

• On 28 November 2022, the Administrative Boundaries dataset originally released on 22 November 2022 was amended and re-uploaded after Geoscape identified some issues with the original data for 'Electoral Boundaries'.
• As a result of the error, some shapefiles were published in 3D rather than 2D, which may affect some users when importing data into GIS applications.
• The error affected the Electoral Boundaries dataset, specifically the Commonwealth boundary data for Victoria and Western Australia, including 'All States'.
• Only the ESRI Shapefile formats were affected (both GDA94 and GDA2020). The MapInfo TAB format was not affected.
• Because the datasets are zipped into a single file, once the error was fixed by Geoscape all of Administrative Boundaries shapefiles had to be re-uploaded, rather than only the affected files.
• If you downloaded either of the two Administrative Boundary ESRI Shapefiles between 22 November and 28 November 2022 and plan to use the Electoral Boundary component, you are advised to download the revised version dated 28 November 2022. Apologies for any inconvenience.

Further information on Administrative Boundaries, including FAQs on the data, is available here or through Geoscape Australia’s network of partners. They provide a range of commercial products based on Administrative Boundaries, including software solutions, consultancy and support.

Note: On 1 October 2020, PSMA Australia Limited began trading as Geoscape Australia.

The Australian Government has negotiated the release of Administrative Boundaries to the whole economy under an open CCBY 4.0 licence.

Users must only use the data in ways that are consistent with the Australian Privacy Principles issued under the Privacy Act 1988 (Cth).

Users must also note the following attribution requirements:

Preferred attribution for the Licensed Material:

Administrative Boundaries © Geoscape Australia licensed by the Commonwealth of Australia under Creative Commons Attribution 4.0 International license (CC BY 4.0).

Preferred attribution for Adapted Material:

Incorporates or developed using Administrative Boundaries © Geoscape Australia licensed by the Commonwealth of Australia under Creative Commons Attribution 4.0 International licence (CC BY 4.0).

What to Expect When You Download Administrative Boundaries

Administrative Boundaries is large dataset (around 1.5GB unpacked), made up of seven themes each containing multiple layers.

Users are advised to read the technical documentation including the product change notices and the individual product descriptions before downloading and using the product.

Please note this dataset is the most recent version of the Administrative Boundaries (AB). For previous versions of the AB please go to this url: https://data.gov.au/dataset/ds-dga-b4ad5702-ea2b-4f04-833c-d0229bfd689e/details?q=previous

License Information

This dataset contains shapefile boundaries for CA State, counties and places from the US Census Bureau's 2023 MAF/TIGER database. Current geography in the 2023 TIGER/Line Shapefiles generally reflects the boundaries of governmental units in effect as of January 1, 2023.

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.

This file contains European countries in a shapefile format that can be used in python, R or matlab. The file has been created by Drin Marmullaku based on GADM version 4.1 (https://gadm.org/) and distributed according to their license (https://gadm.org/license.html).

Please cite as: Sevdari, Kristian; Marmullaku, Drin (2023). Shapefile of European countries. Technical University of Denmark. Dataset. https://doi.org/10.11583/DTU.23686383 This dataset is distributed under a CCBY-NC-SA 4.0 license

Using the data to create maps for publishing of academic research articles is allowed. Thus you can use the maps you made with GADM data for figures in articles published by PLoS, Springer Nature, Elsevier, MDPI, etc. You are allowed (but not required) to publish these articles (and the maps they contain) under an open license such as CC-BY as is the case with PLoS journals and may be the case with other open access articles. Data for the following countries is covered by a a different license Austria: Creative Commons Attribution-ShareAlike 2.0 (source: Government of Austria)

The TIGER/Line shapefiles 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 primary legal divisions of most states are termed counties. In Louisiana, these divisions are known as parishes. In Alaska, which has no counties, the equivalent entities are the organized boroughs, city and boroughs, municipalities, and for the unorganized area, census areas. The latter are delineated cooperatively for statistical purposes by the State of Alaska and the Census Bureau. In four states (Maryland, Missouri, Nevada, and Virginia), there are one or more incorporated places that are independent of any county organization and thus constitute primary divisions of their states. These incorporated places are known as independent cities and are treated as equivalent entities for purposes of data presentation. The District of Columbia and Guam have no primary divisions, and each area is considered an equivalent entity for purposes of data presentation. The Census Bureau treats the following entities as equivalents of counties for purposes of data presentation: Municipios in Puerto Rico, Districts and Islands in American Samoa, Municipalities in the Commonwealth of the Northern Mariana Islands, and Islands in the U.S. Virgin Islands. The entire area of the United States, Puerto Rico, and the Island Areas is covered by counties or equivalent entities. The boundaries for counties and equivalent entities are as of January 1, 2017, primarily as reported through the Census Bureau's Boundary and Annexation Survey (BAS).

Context

This dataset contains shapefiles outlining 558 neighborhoods in 50 major cities in New York state, notably including Albany, Buffalo, Ithaca, New York City, Rochester, and Syracuse. This adds context to your datasets by identifying the neighborhood of any locations you have, as coordinates on their own don't carry a lot of information.

Content

What's inside is more than just rows and columns. Make it easy for others to get started by describing how you acquired the data and what time period it represents, too. What fields does it include? What's the time period of the data and how was it collected?

Four files are included containing data about the shapes: an SHX file, a DBF file, an SHP file, and a PRJ file. Including all of them in your input data are necessary, as they all contain pieces of the data; one file alone will not have everything that you need.

Seeing how none of these files are plaintext, it can be a little difficult to get set up with them. I highly recommend using mapshaper.org to get started- this site will show you the boundaries drawn on a plane, as well as allow you to export the files in a number of different formats (e.g. GeoJSON, CSV) if you are unable to use them in the format they are provided in. Personally, I have found it easier to work with the shapefile format though.

To get started with the shapefile in R, you can use the the rgdal and rgeos packages. To see an example of these being used, be sure to check out my kernel, "Incorporating neighborhoods into your model".

Acknowledgements

These files were provided by Zillow and are available under a Creative Commons license.

Inspiration

I'll be using these in the NYC Taxi Trip Duration competition to add context to the pickup and dropoff locations of the taxi rides and hopefully greatly improve my predictions.

The dataset collection consists of maps of Sweden, sourced from the Swedish website 'Lantmäteriet' (The Land Survey). The maps are provided in Shape and MapInfo *.tab formats, and use the SWEREF 99 TM (EPSG:3006) coordinate system. The contents of these maps have been selected separately for each scale, ensuring high-quality display. The content includes coastlines, islands, streams, national boundaries, county boundaries, municipality boundaries, the Arctic Circle and grid/degree grids. Please note that the maps on a scale of 1:5 million, 1:10 million and 1:20 million are not updated. For a more detailed description of the content, refer to the product descriptions available in both Swedish and English. The data size for the map of Sweden in a scale of 1:5 million is approximately 0.53 MB, in a scale of 1:10 million is about 0.34 MB, and in a scale of 1:20 million is approximately 0.21 MB. Data in Shape format is delivered in 4 files per layer (geometry file, attribute file in Dbase format, index file, and projection file), while data in MapInfo (tab) format is also delivered in 4 files per layer (main file/table definitions, attribute file, geometry file, and index file for graphical features). These data sets can be retrieved as open data from the website of Lantmäteriet. This dataset is licensed under CC0 (Creative Commons Zero, https://creativecommons.org/public-domain/cc0/).

This dataset represents States and equivalent entities, which are the primary governmental divisions of the United States. The TIGER/Line shapefiles 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. In addition to the fifty States, the Census Bureau treats the District of Columbia, Puerto Rico, and each of the Island Areas (American Samoa, the Commonwealth of the Northern Mariana Islands, Guam, and the U.S. Virgin Islands) as the statistical equivalents of States for the purpose of data presentation.

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.

The geographic data are built from the Technical Information Management System (TIMS). TIMS consists of two separate databases: an attribute database and a spatial database. The attribute information for offshore activities is stored in the TIMS database. The spatial database is a combination of the ARC/INFO and FINDER databases and contains all the coordinates and topology information for geographic features. The attribute and spatial databases are interconnected through the use of common data elements in both databases, thereby creating the spatial datasets. The data in the mapping files are made up of straight-line segments. If an arc existed in the original data, it has been replaced with a series of straight lines that approximate the arc. The Gulf of America OCS Region stores all its mapping data in longitude and latitude format. All coordinates are in NAD 27. Data can be obtained in three types of digital formats: INTERACTIVE MAP: The ArcGIS web maps are an interactive display of geographic information, containing a basemap, a set of data layers (many of which include interactive pop-up windows with information about the data), an extent, navigation tools to pan and zoom, and additional tools for geospatial analysis. SHP: A Shapefile is a digital vector (non-topological) storage format for storing geometric location and associated attribute information. Shapefiles can support point, line, and area features with attributes held in a dBASE format file. GEODATABASE: An ArcGIS geodatabase is a collection of geographic datasets of various types held in a common file system folder, a Microsoft Access database, or a multiuser relational DBMS (such as Oracle, Microsoft SQL Server, PostgreSQL, Informix, or IBM DB2). The geodatabase is the native data structure for ArcGIS and is the primary data format used for editing and data management.

Data for Figure Atlas.2 from Atlas of the Working Group I (WGI) Contribution to the Intergovernmental Panel on Climate Change (IPCC) Sixth Assessment Report (AR6).

Figure Atlas.2 shows WGI reference regions used in the (a) AR5 and (b) AR6 reports.

How to cite this dataset

When citing this dataset, please include both the data citation below (under 'Citable as') and the following citations: For the report component from which the figure originates: Gutiérrez, J.M., R.G. Jones, G.T. Narisma, L.M. Alves, M. Amjad, I.V. Gorodetskaya, M. Grose, N.A.B. Klutse, S. Krakovska, J. Li, D. Martínez-Castro, L.O. Mearns, S.H. Mernild, T. Ngo-Duc, B. van den Hurk, and J.-H. Yoon, 2021: Atlas. In Climate Change 2021: The Physical Science Basis. Contribution of Working Group I to the Sixth Assessment Report of the Intergovernmental Panel on Climate Change [Masson-Delmotte, V., P. Zhai, A. Pirani, S.L. Connors, C. Péan, S. Berger, N. Caud, Y. Chen, L. Goldfarb, M.I. Gomis, M. Huang, K. Leitzell, E. Lonnoy, J.B.R. Matthews, T.K. Maycock, T. Waterfield, O. Yelekçi, R. Yu, and B. Zhou (eds.)]. Cambridge University Press, Cambridge, United Kingdom and New York, NY, USA, pp. 1927–2058, doi:10.1017/9781009157896.021

Iturbide, M. et al., 2021: Repository supporting the implementation of FAIR principles in the IPCC-WG1 Interactive Atlas. Zenodo. Retrieved from: http://doi.org/10.5281/zenodo.5171760

Figure subpanels

The figure has two panels, with data provided for both panels in the master GitHub repository linked in the documentation.

Data provided in relation to figure

This dataset contains the corner coordinates defining each reference region for the second panel of the figure, which contain coordinate information at a 0.44º resolution. The repository directory 'reference-regions' contains data provided for the reference regions as polygons in different formats (CSV with coordinates, R data, shapefile and geojson) together with R and Python notebooks illustrating the use of these regions with worked examples.

Data for reference regions for AR5 can be found here: https://catalogue.ceda.ac.uk/uuid/a3b6d7f93e5c4ea986f3622eeee2b96f

CMIP5 is the fifth phase of the Coupled Model Intercomparison Project. CMIP6 is the sixth phase of the Coupled Model Intercomparison Project. CORDEX is The Coordinated Regional Downscaling Experiment from the WCRP. AR5 and AR6 refer to the 5th and 6th Annual Report of the IPCC. WGI stands for Working Group I

Notes on reproducing the figure from the provided data

Data and figures produced by the Jupyter Notebooks live inside the notebooks directory. The notebooks describe step by step the basic process followed to generate some key figures of the AR6 WGI Atlas and some products underpinning the Interactive Atlas, such as reference regions, global warming levels, aggregated datasets. They include comments and hints to extend the analysis, thus promoting reusability of the results. These notebooks are provided as guidance for practitioners, more user friendly than the code provided as scripts in the reproducibility folder.

Some of the notebooks require access to large data volumes out of this repository. To speed up the execution of the notebook, in addition to the full code to access the data, we provide a data loading shortcut, by storing intermediate results in the auxiliary-material folder in this repository. To test other parameter settings, the full data access instructions should be followed, which can take long waiting times.

Sources of additional information

The following weblinks are provided in the Related Documents section of this catalogue record: - Link to the figure on the IPCC AR6 website - Link to the report component containing the figure (Atlas) - Link to the Supplementary Material for Atlas, which contains details on the input data used in Table Atlas.SM.15. - Link to the code for the figure, archived on Zenodo. - Link to the necessary notebooks for reproducing the figure from GitHub. - Link to IPCC AR5 reference regions dataset

This city boundary shapefile was extracted from Esri Data and Maps for ArcGIS 2014 - U.S. Populated Place Areas. This shapefile can be joined to 500 Cities city-level Data (GIS Friendly Format) in a geographic information system (GIS) to make city-level maps.

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

This data set shows designated and actual irrigation areas in Australia compiled by the National Land Use Mapping Project of the National Land and Water Resources Audit to assist in the identification of irrigation areas in Australia. Additional data custodians include Agriculture WA, Queensland Department of Natural Resources and Mines, Murray-Darling Basin Commission, New South Wales Department of Land and Water Conservation and Tasmanian Department of Primary Industries, Water and Environment Designated irrigation areas indicate areas with administratively defined boundaries which have associated rights and obligations pertaining to use of water for irrigation. The precise meaning of the term designated irrigation area varies from region to region. aActual irrigation areasa indicate areas with observationally defined boundaries within which irrigation is practised. The boundaries have been supplied by various agencies and cover the more important irrigation areas in Australia. Users of this data set should be aware that there are irrigated areas outside the designated and actual areas shown and that there are non-irrigated areas inside them. This is particularly true of Tasmania and the Murray-Darling Basin.The data set is available in both vector and raster formats. The raster data set can be used as a companion to the 1996/97 Land Use of Australia data set which is also in raster format. Both data sets have the same coordinate system, boundary coordinates and cell size so that they can easily be overlaid. Users may find, however, that some cells are classified as irrigated by the Australian Irrigation Areas data set and as non-agricultural land by the 1996/97 Land Use of Australia data set.The Version 1a data set may be of use to researchers and policy makers in need of national, regional or local scale irrigation data, though the scale of the source material is highly variable and completness of coverage is poor in some regions.

See further metadata for more detail.

Lineage: The data set was constructed in vector format by appending irrigation area boundary data sets supplied by various agencies. The component data sets are listed below. One of the component data sets which was supplied as separate tiles in ArcView shapefile format was assembled into a single shapefile data set in ArcView 3.1. All other processing was carried out in ARC/INFO 7.2.1 under SunOS using double precision coordinates. For all operations in which processing used a fuzzy tolerance, the value specified was 0.00001 degrees (about 1 m). The raster form of the data set was made from the vector form. 1) Ord River Scheme, Stage 1, irrigation area boundaries. This data set was supplied by Agriculture WA in ArcView shapefile format.2) Boundary of Gazetted Irrigation Areas in Queensland. This data set was supplied by the Queensland Department of Natural Resources and Mines in ARC/INFO export file format. It shows designated irrigation areas. The coordinate datum is not known with certainty and was assumed to be the Australian Geodetic Datum 1984.3) Northern Murray-Darling Basin irrigation area boundaries. This data set was supplied by the Murray-Darling Basin Commission in ARC/INFO export file format. It shows actual irrigation areas, based on interpretation of coarse scale imagery derived from Landsat TM images. The data set comprises 11 polygons. Of these, five have not been retained in the national data set because they largely coincide with the much higher resolution polygons of the Northern New South Wales Cotton Development data set. A sixth has not been retained because it proves to be almost entirely covered by a national park and a perennial lake. One of the polygons that was retained was edited to give precedence to a higher resolution polygon in the Boundary of Gazetted Irrigation Areas in Queensland data set which it partly overlies.4) Northern New South Wales Cotton Development data set. This data set was supplied by the New South Wales Department of Land and Water Conservation, in ArcView shapefile format, as 50 separate tiles. It shows actual irrigation areas and a variety of other land uses and land covers related to cotton growing. It is based on interpretation of aerial photography and satellite imagery with extensive field checking. Only the polygons showing irrigation areas were included in the national data set. The tiles were merged in ArcView using the merge function of the GeoProcessing Wizard. Further processing was undertaken in AR

Crowther_Nature_Files.zip This description pertains to the original download. Details on revised (newer) versions of the datasets are listed below. When more than one version of a file exists in Figshare, the original DOI will take users to the latest version, though each version technically has its own DOI. -- Two global maps (raster files) of tree density. These maps highlight how the number of trees varies across the world. One map was generated using biome-level models of tree density, and applied at the biome scale. The other map was generated using ecoregion-level models of tree density, and applied at the ecoregion scale. For this reason, transitions between biomes or between ecoregions may be unrealistically harsh, but large-scale estimates are robust (see Crowther et al 2015 and Glick et al 2016). At the outset, this study was intended to generate reliable estimates at broad spatial scales, which inherently comes at the cost of fine-scale precision. For this reason, country-scale (or larger) estimates are generally more robust than individual pixel-level estimates. Additionally, due to data limitations, estimates for Mangroves and Tropical coniferous forest (as identified by WWF and TNC) were generated using models constructed from Topical moist broadleaf forest data and Temperate coniferous forest data, respectively. Because we used ecological analogy, the estimates for these two biomes should be considered less reliable than those of other biomes . These two maps initially appeared in Crowther et al (2015), with the biome map being featured more prominently. Explicit publication of the data is associated with Glick et al (2016). As they are produced, updated versions of these datasets, as well as alternative formats, will be made available under Additional Versions (see below).

Methods: We collected over 420,000 ground-sources estimates of tree density from around the world. We then constructed linear regression models using vegetative, climatic, topographic, and anthropogenic variables to produce forest tree density estimates for all locations globally. All modeling was done in R. Mapping was done using R and ArcGIS 10.1.

Viewing Instructions: Load the files into an appropriate geographic information system (GIS). For the original download (ArcGIS geodatabase files), load the files into ArcGIS to view or export the data to other formats. Because these datasets are large and have a unique coordinate system that is not read by many GIS, we suggest loading them into an ArcGIS dataframe whose coordinate system matches that of the data (see File Format). For GeoTiff files (see Additional Versions), load them into any compatible GIS or image management program.

Comments: The original download provides a zipped folder that contains (1) an ArcGIS File Geodatabase (.gdb) containing one raster file for each of the two global models of tree density – one based on biomes and one based on ecoregions; (2) a layer file (.lyr) for each of the global models with the symbology used for each respective model in Crowther et al (2015); and an ArcGIS Map Document (.mxd) that contains the layers and symbology for each map in the paper. The data is delivered in the Goode homolosine interrupted projected coordinate system that was used to compute biome, ecoregion, and global estimates of the number and density of trees presented in Crowther et al (2015). To obtain maps like those presented in the official publication, raster files will need to be reprojected to the Eckert III projected coordinate system. Details on subsequent revisions and alternative file formats are list below under Additional Versions.----------

Additional Versions: Crowther_Nature_Files_Revision_01.zip contains tree density predictions for small islands that are not included in the data available in the original dataset. These predictions were not taken into consideration in production of maps and figures presented in Crowther et al (2015), with the exception of the values presented in Supplemental Table 2. The file structure follows that of the original data and includes both biome- and ecoregion-level models.

Crowther_Nature_Files_Revision_01_WGS84_GeoTiff.zip contains Revision_01 of the biome-level model, but stored in WGS84 and GeoTiff format. This file was produced by reprojecting the original Goode homolosine files to WGS84 using nearest neighbor resampling in ArcMap. All areal computations presented in the manuscript were computed using the Goode homolosine projection. This means that comparable computations made with projected versions of this WGS84 data are likely to differ (substantially at greater latitudes) as a product of the resampling. Included in this .zip file are the primary .tif and its visualization support files.

References:

Crowther, T. W., Glick, H. B., Covey, K. R., Bettigole, C., Maynard, D. S., Thomas, S. M., Smith, J. R., Hintler, G., Duguid, M. C., Amatulli, G., Tuanmu, M. N., Jetz, W., Salas, C., Stam, C., Piotto, D., Tavani, R., Green, S., Bruce, G., Williams, S. J., Wiser, S. K., Huber, M. O., Hengeveld, G. M., Nabuurs, G. J., Tikhonova, E., Borchardt, P., Li, C. F., Powrie, L. W., Fischer, M., Hemp, A., Homeier, J., Cho, P., Vibrans, A. C., Umunay, P. M., Piao, S. L., Rowe, C. W., Ashton, M. S., Crane, P. R., and Bradford, M. A. 2015. Mapping tree density at a global scale. Nature, 525(7568): 201-205. DOI: http://doi.org/10.1038/nature14967Glick, H. B., Bettigole, C. B., Maynard, D. S., Covey, K. R., Smith, J. R., and Crowther, T. W. 2016. Spatially explicit models of global tree density. Scientific Data, 3(160069), doi:10.1038/sdata.2016.69.

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.

Content

This dataset contains a geological map of the Afar Depression (1:1’000’000), including all the associated data.

This dataset includes:

The map in JPEG, PDF, and GeoTIFF format

The shapefiles of the map

One document listing all sources used for the compilation of this map (Source_Material_Afar Depression.pdf)

One document describing the uncertainty of the map (Reliability_geol_map.pdf)

One dating database compiling published datings from the literature in .txt and shapefile formats. This database has been reviewed and mistakes in coordinates were corrected (see comments column). The precision of the position is also evaluated (1 = poor - possibly up to more than 10km uncertainty; 2 = average - no precise GPS measurement of the coordinates but good localisation on map or description of the outcrop; 3 = very good - most of the time GPS measurement or very precise descriptions/map).

This database is an additional complement to the paper ‘Rime, V., Foubert, A., Ruch, J. & Kidane, T. (in prep.), Tectonostratigraphic evolution and significance of the Afar Depression’.

References

The map was developed by compiling a large number of published maps, descriptions, datings and other studies, complemented by fieldwork and remote sensing. All sources and references are mentioned in the Source_Material_Afar_Depression. Material and methods of mapping have been described in detail within the paper.

Citation

When using the data, please cite the data as ‘Rime, V., Foubert, A., Atnafu, B. & Kidane, T. (2022) Geological map of the Afar Depression. Zenodo’ and refer to the accompanying paper as ‘Rime, V., Foubert, A., Ruch, J. & Kidane, T. (in prep.) Tectonostratigraphic evolution and significance of the Afar Depression’

The map and additional data are given without any guarantee of correctness. Any use of these are under the user’s full responsibility. The authors decline any responsibility.

Acknowledgements

This study was funded by the Swiss National Science Foundation (SNF project SERENA – SEdimentary REcord of the Northern Afar 200021_163114). We are grateful to the University of Fribourg (Switzerland), the University of Addis Ababa (Ethiopia), the Ethiopian Ministry of Mines and Energy, the Ethiopian Geological Survey, Circum Minerals, former Allana Potash and Yara Dallol for their support. We particularly acknowledge Samuel Getachew that helped us to access some of the geological maps. We thank David Jaramillo-Vogel, Jean-Charles Schaegis, Haileyesus Negga, Addis Endeshaw, Ermias Gebru, Eva de Boever, Juan-Carlos Braga, Pia Wyler, Xenia Haberditz, the Ethioder team as well as the regional and local administration of the Afar for their help and support during fieldwork.