The files linked to this reference are the geospatial data created as part of the completion of the baseline vegetation inventory project for the NPS park unit. Current format is ArcGIS file geodatabase but older formats may exist as shapefiles. We converted the photointerpreted data into a format usable in a geographic information system (GIS) by employing three fundamental processes: (1) orthorectify, (2) digitize, and (3) develop the geodatabase. All digital map automation was projected in Universal Transverse Mercator (UTM), Zone 16, using the North American Datum of 1983 (NAD83). Orthorectify: We orthorectified the interpreted overlays by using OrthoMapper, a softcopy photogrammetric software for GIS. One function of OrthoMapper is to create orthorectified imagery from scanned and unrectified imagery (Image Processing Software, Inc., 2002). The software features a method of visual orientation involving a point-and-click operation that uses existing orthorectified horizontal and vertical base maps. Of primary importance to us, OrthoMapper also has the capability to orthorectify the photointerpreted overlays of each photograph based on the reference information provided. Digitize: To produce a polygon vector layer for use in ArcGIS (Environmental Systems Research Institute [ESRI], Redlands, California), we converted each raster-based image mosaic of orthorectified overlays containing the photointerpreted data into a grid format by using ArcGIS. In ArcGIS, we used the ArcScan extension to trace the raster data and produce ESRI shapefiles. We digitally assigned map-attribute codes (both map-class codes and physiognomic modifier codes) to the polygons and checked the digital data against the photointerpreted overlays for line and attribute consistency. Ultimately, we merged the individual layers into a seamless layer. Geodatabase: At this stage, the map layer has only map-attribute codes assigned to each polygon. To assign meaningful information to each polygon (e.g., map-class names, physiognomic definitions, links to NVCS types), we produced a feature-class table, along with other supportive tables and subsequently related them together via an ArcGIS Geodatabase. This geodatabase also links the map to other feature-class layers produced from this project, including vegetation sample plots, accuracy assessment (AA) sites, aerial photo locations, and project boundary extent. A geodatabase provides access to a variety of interlocking data sets, is expandable, and equips resource managers and researchers with a powerful GIS tool.

Acknowledgements: The CORE format was proudly inspired by the Cloud Optimized GeoTIFF (COG) format, by considering how to leverage the ability of clients issuing ​HTTP GET range requests for a time-series of remote sensing and aerial imagery (instead of just one image).

License: The Cloud Optimized Raster Encoding (CORE) specifications are released to the public domain under a Creative Commons 1.0 CC0 "No Rights Reserved" international license. You can reuse the information contained herein in any way you want, for any purposes and without restrictions.

Summary: The Cloud Optimized Raster Encoding (CORE) format is being developed for the efficient storage and management of gridded data by applying video encoding algorithms. It is mainly designed for the exchange and preservation of large time series data in environmental data repositories, while in the same time enabling more efficient workflows on the cloud. It can be applied to any large number of similar (in pixel size and image dimensions) raster data layers. CORE is not designed to replace COG but to work together with COG for a collection of many layers (e.g. by offering a fast preview of layers when switching between layers of a time series). WARNING: Currently only applicable to RGB/Byte imagery. The final CORE specifications may probably be very different from what is written herein or CORE may not ever become productive due to a myriad of reasons (see also 'Major issues to be solved'). With this early public sharing of the format we explicitly support the Open Science agenda, which implies "shifting from the standard practices of publishing research results in scientific publications towards sharing and using all available knowledge at an earlier stage in the research process" (quote from: European Commission, Directorate General for Research and Innovation, 2016. Open innovation, open science, open to the world). CORE Specifications: 1) a MP4 or WebM video digital multimedia container format (or any future video container playable as HTML video in major browsers) 2) a free to use or open video compression codec such as H.264, VP9, or AV1 (or any future video codec that is open sourced or free to use for end users) Note: H.264 is currently recommended because of the wide usage with support in all major browsers, fast encoding due to acceleration in hardware (which is currently not the case for AV1 or VP9) and the fact that MPEG LA has allowed the free use for streaming video that is free to the end users. However, please note that H.264 is restricted by patents and its use in proprietary or commercial software requires the payment of royalties to MPEG LA. However, when AV1 matures and accelerated hardware encoding becomes available, AV1 is expected to offer 30% to 50% smaller file size in comparison with H.264, while retaining the same quality. 3) the encoding frame rate should be of one frame per second (fps) with each layer segmented in internal tiles, similar to COG, ordered by the main use case when accessing the data: either layer contiguous or tile contiguous; Note: The internal tile arrangement should support an easy navigation inside the CORE video format, depending on the use case. 4) a CORE file is optimised for streaming with the moov atom at the beginning of the file (e.g. with -movflags faststart) and optional additional optimisations depending on the codec used (e.g. -tune fastdecode -tune zerolatency for H.264) 5) metadata tags inside the moov atom for describing and using geographic image data (that are preferably compatible with the OGC GeoTIFF standard or any future standard accepted by the geospatial community) as well as list of original file names corresponding to each CORE layer 6) it needs to encode similar source rasters (such as time series of rasters with the same extent and resolution, or different tiles of the same product; each input raster should be having the same image and pixel size) 7) it provides a mechanism for addressing and requesting overviews (lower resolution data) for a fast display in web browser depending on the map scale (currently external overviews) Major issues to be solved: - Internal overviews (similar to COG), by chaining lower resolution videos in the same MP4 container for fast access to overviews first); Currently, overviews are kept as separate files, as external overviews. - Metadata encoding (how to best encode spatial extent, layer names, and so on, for each of the layer inside the series, which may have a different geographical extent, etc...; Known issues: adding too many tags with FFmpeg which are not part of the standard MP4 moov atom; metadata tags have a limited string length. - Applicability beyond RGB/Byte datasets; defining a standard way of converting cell values from Int16/UInt16/UInt32/Int32/Float32/Float64/ data types into multi-band Byte values (and reconstructing them back to the original data type within acceptable thresholds) Example Notice: The provided CORE (.mp4) examples contain modified Copernicus Sentinel data [2018-2021]. For generating the CORE examples provided, 50 original Sentinel 2 (S-2) TCI data images from an area located inside Switzerland were downloaded from www.copernicus.eu, and then transformed into CORE format using ffmpeg with H.264 encoding using the x264 library. DISCLAIMER: Basic scripts are provided for the Geomatics peer review (in 2021) and kept as additional information for the dataset. Nevertheless, please note that software dependencies and libraries, as well as cloud storage paths, may quickly become deprecated over time (after 2021). For compatibility, stable dependencies and libraries released around 2020 should be used.

In this course, you will learn to work within the free and open-source R environment with a specific focus on working with and analyzing geospatial data. We will cover a wide variety of data and spatial data analytics topics, and you will learn how to code in R along the way. The Introduction module provides more background info about the course and course set up. This course is designed for someone with some prior GIS knowledge. For example, you should know the basics of working with maps, map projections, and vector and raster data. You should be able to perform common spatial analysis tasks and make map layouts. If you do not have a GIS background, we would recommend checking out the West Virginia View GIScience class. We do not assume that you have any prior experience with R or with coding. So, don't worry if you haven't developed these skill sets yet. That is a major goal in this course. Background material will be provided using code examples, videos, and presentations. We have provided assignments to offer hands-on learning opportunities. Data links for the lecture modules are provided within each module while data for the assignments are linked to the assignment buttons below. Please see the sequencing document for our suggested order in which to work through the material. After completing this course you will be able to: prepare, manipulate, query, and generally work with data in R. perform data summarization, comparisons, and statistical tests. create quality graphs, map layouts, and interactive web maps to visualize data and findings. present your research, methods, results, and code as web pages to foster reproducible research. work with spatial data in R. analyze vector and raster geospatial data to answer a question with a spatial component. make spatial models and predictions using regression and machine learning. code in the R language at an intermediate level.

This zip file contains geodatabases with raster mosaic datasets. The raster mosaic datasets consist of georeferenced tiff images of mineral potential maps, their associated metadata, and descriptive information about the images. These images are duplicates of the images found in the georeferenced tiff images zip file. There are four geodatabases containing the raster mosaic datasets, one for each of the four SaMiRA report areas: North-Central Montana; North-Central Idaho; Southwestern and South-Central Wyoming and Bear River Watershed; and Nevada Borderlands. The georeferenced images were clipped to the extent of the map and all explanatory text, gathered from map explanations or report text was imported into the raster mosaic dataset database as ‘Footprint’ layer attributes. The data compiled into the 'Footprint' layer tables contains the figure caption from the original map, online linkage to the source report when available, and information on the assessed commodities according to the legal definition of mineral resources—metallic, non-metallic, leasable non-fuel, leasable fuel, geothermal, paleontological, and saleable. To use the raster mosaic datasets in ArcMap, click on “add data”, double click on the [filename].gdb, and add the item titled [filename]_raster_mosaic. This will add all of the images within the geodatabase as part of the raster mosaic dataset. Once added to ArcMap, the raster mosaic dataset appears as a group of three layers under the mosaic dataset. The first item in the group is the ‘Boundary’, which contains a single polygon representing the extent of all images in the dataset. The second item is the ‘Footprint’, which contains polygons representing the extent of each individual image in the dataset. The ‘Footprint’ layer also contains the attribute table data associated with each of the images. The third item is the ‘Image’ layer and contains the images in the dataset. The images are overlapping and must be selected and locked, or queried in order to be viewed one at a time. Images can be selected from the attribute table, or can be selected using the direct select tool. When using the direct select tool, you will need to deselect the ‘overviews’ after clicking on an image or group of images. To do this, right click on the ‘Footprint’ layer and hover over ‘Selection’, then click ‘Reselect Only Primary Rasters’. To lock a selected image after selecting it, right-click on the ‘Footprint’ layer in the table of contents window and hover over ‘Selection’, then click ‘Lock To Selected Rasters’. Another way to view a single image is to run a definition query on the image. This is done by right clicking on the raster mosaic in the table of contents and opening the layer properties box. Then click on the ‘Definition Query’ tab and create a query for the desired image.

Polygon layer representing United States counties with name attributes.About Natural EarthNatural Earth is a convenient resource for creating custom maps. Unlike other map data intended for analysis or detailed government mapping, it is designed to meet the needs of cartographers and designers to make generalized maps. Maximum flexibility is a goal.Natural Earth is a public domain collection of map datasets available at 1:10 million (larger scale/more detailed), 1:50 million (medium scale/moderate detail), and 1:110 million (small scale/coarse detail) scales. It features tightly integrated vector and raster data to create a variety of visually pleasing, well-crafted maps with cartography or GIS software. Natural Earth data is made possible by many volunteers and supported by the North American Cartographic Information Society (NACIS).Convenience – Natural Earth solves a problem: finding suitable data for making small-scale maps. In a time when the web is awash in geospatial data, cartographers are forced to waste time sifting through confusing tangles of poorly attributed data to make clean, legible maps. Because your time is valuable, Natural Earth data comes ready to use.Neatness Counts–The carefully generalized linework maintains consistent, recognizable geographic shapes at 1:10m, 1:50m, and 1:110m scales. Natural Earth was built from the ground up, so you will find that all data layers align precisely with one another. For example, where rivers and country borders are one and the same, the lines are coincident.GIS Attributes – Natural Earth, however, is more than just a collection of pretty lines. The data attributes are equally important for mapmaking. Most data contain embedded feature names, which are ranked by relative importance. Other attributes facilitate faster map production, such as width attributes assigned to river segments for creating tapers. Intelligent dataThe attributes assigned to Natural Earth vectors make for efficient mapmaking. Most lines and areas contain embedded feature names, which are ranked by relative importance. Up to eight rankings per data theme allow easy custom map “mashups” to emphasize your subject while de-emphasizing reference features. Other attributes focus on map design. For example, width attributes assigned to rivers allow you to create tapered drainages. Assigning different colors to contiguous country polygons is another task made easier thanks to data attribution.Other key featuresVector features include name attributes and bounding box extents. Know that the Rocky Mountains are larger than the Ozarks.Large polygons are split for more efficient data handling—such as bathymetric layers.Projection-friendly vectors precisely match at 180 degrees longitude. Lines contain enough data points for smooth bending in conic projections, but not so many that computer processing speed suffers.Raster data includes grayscale-shaded relief and cross-blended hypsometric tints derived from the latest NASA SRTM Plus elevation data and tailored to register with Natural Earth Vector.Optimized for use in web mapping applications, with built-in scale attributes to assist features to be shown at different zoom levels.

This database was prepared using a combination of materials that include aerial photographs, topographic maps (1:24,000 and 1:250,000), field notes, and a sample catalog. Our goal was to translate sample collection site locations at Yellowstone National Park and surrounding areas into a GIS database. This was achieved by transferring site locations from aerial photographs and topographic maps into layers in ArcMap. Each field site is located based on field notes describing where a sample was collected. Locations were marked on the photograph or topographic map by a pinhole or dot, respectively, with the corresponding station or site numbers. Station and site numbers were then referenced in the notes to determine the appropriate prefix for the station. Each point on the aerial photograph or topographic map was relocated on the screen in ArcMap, on a digital topographic map, or an aerial photograph. Several samples are present in the field notes and in the catalog but do not corresp ...

A spatial tiling index designed for storage of file-based image and other raster (i.e., LiDAR elevation, landcover) data sets. A regular grid with origin at 0,0 of the Washington North State Plane Coordinate System, with grid cells defined by orthogonal bounds 7500 feet long in easting and in northing. Only those cells currently involved in one of several image/raster data projects for King County and southwestern Snohomish County are labelled, though the labeling scheme can be extended. The name of the spatial index is derived from the acronym (I)n(D)e(X) (P)olygons at the (7500) foot tile level, or idxp7500. Cell label is a row-id cocantenated with a column-id generating a four-character identifier that uniquely identifies every cell. The row portion of the identifier is a two-character alpha code of the format aa, ab, ac.... ba, bb, etc. and the column portion is a two-digit integer value such as 01, 02, 03.... 11,12,13, etc. A composite cell identifier would be then, for example, aa01, aa02, .....ba11,ba12, etc. Not all image and raster data is stored at the tiling level represented by this index. Data is stored at this level if full-resolution, uncompressed data would generate larger than manageable file sizes at a larger tile size.

This dataset consists of three raster datasets representing population density for the years 1990, 2000, and 2010. All three rasters are based on block-level census geography data. The 1990 and 2000 data are derived from data normalized to 2000 block boundaries, while the 2010 data are based on 2010 block boundaries. The 1990 and 2000 data are rasters at 100-meter (m) resolution, while the 2010 data are at 60-m resolution. See details about each dataset in the specific metadata for each raster.

This dataset consists of raster geotiff outputs of annual map projections of land use and land cover for the California Central Valley for the period 2011-2101 across 5 future scenarios. Four of the scenarios were developed as part of the Central Valley Landscape Conservation Project. The 4 original scenarios include a Bad-Business-As-Usual (BBAU; high water availability, poor management), California Dreamin’ (DREAM; high water availability, good management), Central Valley Dustbowl (DUST; low water availability, poor management), and Everyone Equally Miserable (EEM; low water availability, good management). These scenarios represent alternative plausible futures, capturing a range of climate variability, land management activities, and habitat restoration goals. We parameterized our models based on close interpretation of these four scenario narratives to best reflect stakeholder interests, adding a baseline Historical Business-As-Usual scenario (HBAU) for comparison. For these future map projections, the model was initialized in 2011 and run forward on an annual time step to 2101. Each filename has the associated scenario ID (scn418 = DUST, scn419 = DREAM, scn420 = HBAU, scn421 = BBAU, and scn426 = EEM), State Class identification as “sc”, model iteration (= it1 in all cases as only 1 Monte Carlo simulation was modeled), and timestep as “ts” information embedded in the file naming convention. For example, the filename scn418.sc.it1.ts2027.tif represents the DUST scenario (scn418), state class information (sc), iteration 1 (it1), for the 2027 model year (ts2027). The full methods and results of this research are described in detail in the parent manuscript "Integrated modeling of climate, land use, and water availability scenarios and their impacts on managed wetland habitat: A case study from California’s Central Valley" (2021).

The raster_runif data source covers the Flanders and Brussels region and has a resolution of 32 meters. The raster cells with non-missing values match the value-cells of the GRTSmaster_habitats data source with a small buffer added. Every raster cell has a random value between 0 and 1 according to the uniform distribution.

An example usage of this raster is its combination with the GRTSmaster_habitats and habitatmap_stdized data sources in order to draw an equal probability sample of habitat types in Flanders. Habitatmap_stdized contains polygons that are partially or fully covered by habitat types. The proportion of a certain type within a polygon is provided by the phab value. We can draw an equal probability sample size n for a certain habitat type as follows:

select all raster cells of GRTSmaster_habitats that overlap with the sampling frame of the target habitat type

keep the raster cells for which the raster_runif value is lower than the phab value of the habitat type within the polygon

finally select the n raster cells with the lowest GRTS ranking number.

The R-code for creating the raster_runif data source can be found in the GitHub repository 'n2khab-preprocessing' at commit ede43a4.

A reading function to return the data source in a standardized way into the R environment is provided by the R-package n2khab.

The GDAL/OGR libraries are open-source, geo-spatial libraries that work with a wide range of raster and vector data sources. One of many impressive features of the GDAL/OGR libraries is the ViRTual (VRT) format. It is an XML format description of how to transform raster or vector data sources on the fly into a new dataset. The transformations include: mosaicking, re-projection, look-up table (raster), change data type (raster), and SQL SELECT command (vector). VRTs can be used by GDAL/OGR functions and utilities as if they were an original source, even allowing for chaining of functionality, for example: have a VRT mosaic hundreds of VRTs that use look-up tables to transform original GeoTiff files. We used the VRT format for the presentation of hydrologic model results, allowing for thousands of small VRT files representing all components of the monthly water balance to be transformations of a single land cover GeoTiff file.

Presentation at 2018 AWRA Spring Specialty Conference: Geographic Information Systems (GIS) and Water Resources X, Orlando, Florida, April 23-25, http://awra.org/meetings/Orlando2018/

For more information about this layer please see the GIS Data Catalog.A spatial tiling index designed for storage of file-based image and other raster (i.e., LiDAR elevation, landcover) data sets. A regular grid with origin at 0,0 of the Washington North State Plane Coordinate System, with grid cells defined by orthogonal bounds 7500 feet long in easting and in northing. Only those cells currently involved in one of several image/raster data projects for King County and southwestern Snohomish County are labelled, though the labeling scheme can be extended. The name of the spatial index is derived from the acronym (I)n(D)e(X) (P)olygons at the (7500) foot tile level, or idxp7500. Cell label is a row-id cocantenated with a column-id generating a four-character identifier that uniquely identifies every cell. The row portion of the identifier is a two-character alpha code of the format aa, ab, ac.... ba, bb, etc. and the column portion is a two-digit integer value such as 01, 02, 03.... 11,12,13, etc. A composite cell identifier would be then, for example, aa01, aa02, .....ba11,ba12, etc. Not all image and raster data is stored at the tiling level represented by this index. Data is stored at this level if full-resolution, uncompressed data would generate larger than manageable file sizes at a larger tile size.

The data source file is a monolayered GeoTIFF in the FLT8S datatype. In GRTSmh_base4frac, the decimal (i.e. base 10) integer values from the raster data source GRTSmaster_habitats (link) have been converted into base 4 fractions, using a precision of 13 digits behind the decimal mark (as needed to cope with the range of values). For example, the integer 16 (= 4^2) has been converted into 0.0000000000100 and 4^12 has been converted into 0.1000000000000.

Long base 4 fractions seem to be handled and stored easier than long (base 4) integers. This approach follows the one of Stevens & Olsen (2004) to represent the reverse hierarchical order in a GRTS sample as base-4-fraction addresses.

See R-code in the GitHub repository 'n2khab-preprocessing' at commit ecadaf5 for the creation from the GRTSmaster_habitats data source.

A reading function to return the data source in a standardized way into the R environment is provided by the R-package n2khab.

Beware that not all GRTS ranking numbers are present in the data source, as the original GRTS raster has been clipped with the Flemish outer borders (i.e., not excluding the Brussels Capital Region).

This data release supports the referenced publication 'Climate futures for lizards and snakes in western North America may result in new species management issues' in this metadata record. Data included in this release includes raster data outputs and resulting summaries from the analyses, described in the processing steps of this metadata record. In summary this release includes information for 129 species and 1 genera of snakes and lizards in western North America. There are 7 rasters for each species and 6 summary rasters for the entire dataset, to total 916 rasters. For each species, rasters display a projected climate-niche at 6 time scenarios and 1 comparison between two scenarios. The summary rasters display calculated richness generated from the individual species rasters for a given time scenario. In addition to the raster data, each species includes an illustration of the comparison raster. The summary data files for this dataset include .csv files that describe the extent and changes of the projected climate-niche space.

Overview:
The Copernicus DEM is a Digital Surface Model (DSM) which represents the surface of the Earth including buildings, infrastructure and vegetation. The original GLO-30 provides worldwide coverage at 30 meters (refers to 10 arc seconds). Note that ocean areas do not have tiles, there one can assume height values equal to zero. Data is provided as Cloud Optimized GeoTIFFs. Note that the vertical unit for measurement of elevation height is meters.

The Copernicus DEM for Europe at 3 arcsec (0:00:03 = 0.00083333333 ~ 90 meter) in COG format has been derived from the Copernicus DEM GLO-30, mirrored on Open Data on AWS, dataset managed by Sinergise (https://registry.opendata.aws/copernicus-dem/).

Processing steps:
The original Copernicus GLO-30 DEM contains a relevant percentage of tiles with non-square pixels. We created a mosaic map in VRT format and defined within the VRT file the rule to apply cubic resampling while reading the data, i.e. importing them into GRASS GIS for further processing. We chose cubic instead of bilinear resampling since the height-width ratio of non-square pixels is up to 1:5. Hence, artefacts between adjacent tiles in rugged terrain could be minimized:

gdalbuildvrt -input_file_list list_geotiffs_MOOD.csv -r cubic -tr 0.000277777777777778 0.000277777777777778 Copernicus_DSM_30m_MOOD.vrt

In order to reduce the spatial resolution to 3 arc seconds, weighted resampling was performed in GRASS GIS (using r.resamp.stats -w and the pixel values were scaled with 1000 (storing the pixels as integer values) for data volume reduction. In addition, a hillshade raster map was derived from the resampled elevation map (using r.relief, GRASS GIS). Eventually, we exported the elevation and hillshade raster maps in Cloud Optimized GeoTIFF (COG) format, along with SLD and QML style files.

Projection + EPSG code:
Latitude-Longitude/WGS84 (EPSG: 4326)

Spatial extent:
north: 82:00:30N
south: 18N
west: 32:00:30W
east: 70E

Spatial resolution:
3 arc seconds (approx. 90 m)

Pixel values:
meters * 1000 (scaled to Integer; example: value 23220 = 23.220 m a.s.l.)

Software used:
GDAL 3.2.2 and GRASS GIS 8.0.0 (r.resamp.stats -w; r.relief)

Original dataset license:
https://spacedata.copernicus.eu/documents/20126/0/CSCDA_ESA_Mission-specific+Annex.pdf

Processed by:
mundialis GmbH & Co. KG, Germany (https://www.mundialis.de/)

This collection consists of geospatial data layers and summary data at the country and country sub-division levels that are part of USAID's Demographic Health Survey Spatial Data Repository. This collection includes geographically-linked health and demographic data from the DHS Program and the U.S. Census Bureau for mapping in a geographic information system (GIS). The data includes indicators related to: fertility, family planning, maternal and child health, gender, HIV/AIDS, literacy, malaria, nutrition, and sanitation. Each set of files is associated with a specific health survey for a given year for over 90 different countries that were part of the following surveys:Demographic Health Survey (DHS)Malaria Indicator Survey (MIS)Service Provisions Assessment (SPA)Other qualitative surveys (OTH)Individual files are named with identifiers that indicate: country, survey year, survey, and in some cases the name of a variable or indicator. A list of the two-letter country codes is included in a CSV file.Datasets are subdivided into the following folders:Survey boundaries: polygon shapefiles of administrative subdivision boundaries for countries used in specific surveys. Indicator data: polygon shapefiles and geodatabases of countries and subdivisions with 25 of the most common health indicators collected in the DHS. Estimates generated from survey data.Modeled surfaces: geospatial raster files that represent gridded population and health indicators generated from survey data, for several countries.Geospatial covariates: CSV files that link survey cluster locations to ancillary data (known as covariates) that contain data on topics including population, climate, and environmental factors.Population estimates: spreadsheets and polygon shapefiles for countries and subdivisions with 5-year age/sex group population estimates and projections for 2000-2020 from the US Census Bureau, for designated countries in the PEPFAR program.Workshop materials: a tutorial with sample data for learning how to map health data using DHS SDR datasets with QGIS. Documentation that is specific to each dataset is included in the subfolders, and a methodological summary for all of the datasets is included in the root folder as an HTML file. File-level metadata is available for most files. Countries for which data included in the repository include: Afghanistan, Albania, Angola, Armenia, Azerbaijan, Bangladesh, Benin, Bolivia, Botswana, Brazil, Burkina Faso, Burundi, Cape Verde, Cambodia, Cameroon, Central African Republic, Chad, Colombia, Comoros, Congo, Congo (Democratic Republic of the), Cote d'Ivoire, Dominican Republic, Ecuador, Egypt, El Salvador, Equatorial Guinea, Eritrea, Eswatini (Swaziland), Ethiopia, Gabon, Gambia, Ghana, Guatemala, Guinea, Guyana, Haiti, Honduras, India, Indonesia, Jordan, Kazakhstan, Kenya, Kyrgyzstan, Lesotho, Liberia, Madagascar, Malawi, Maldives, Mali, Mauritania, Mexico, Moldova, Morocco, Mozambique, Myanmar, Namibia, Nepal, Nicaragua, Niger, Nigeria, Pakistan, Papua New Guinea, Paraguay, Peru, Philippines, Russia, Rwanda, Samoa, Sao Tome and Principe, Senegal, Sierra Leone, South Africa, Sri Lanka, Sudan, Tajikistan, Tanzania, Thailand, Timor-Leste, Togo, Trinidad and Tobago, Tunisia, Turkey, Turkmenistan, Uganda, Ukraine, Uzbekistan, Viet Nam, Yemen, Zambia, Zimbabwe

Overview

These are two multi-annual raster products from the german weather service, that got refined from a 1km grid to a 25m grid, by using a local regression model.

The base rasters from DWD are:

HYRAS precipitation

REGNIE precipitation

DWD-grid (precipitation, potential evapotranspiration and temperature 2m above ground)

To refine the grids the Copernicus DEM with a resolution of 25m got used. For every cell a linear regression model got created, by selecting the multi-annual rasters value and the elevation, from the original digital elevation model that was used by the DWD to create the raster, in a certain window around the cell. This window was at least 2 cells around the considered cell, so 5x5=25 cells. If the standard deviation of the elevation in this window was less than 4m, more neighbooring cells are considered until a maximum of 13x13=169 cells are considered. This widening of the window was necessary for flat regions to get a reasonable regression model.

Out of these combinations of elevation and climate parameter a linear regression model was build. These regression models are then applied to the finer digital elevation model with its 25m resolution from Copernicus.

The following image illustrates the generation of the refined rasters on a small example window:

This geodatabase contains water density raster images for the Gulf of Maine that were interpolated from water density (sigma t or kilograms/ meters cubed) point data acquired from the Canadian Fisheries and Oceans/ Bedford Institute of Oceanography's Hydrographic database.The naming convention of the raster includes the year (or years) included in the the interpolation, the season, and the depth (in meters). So for example, the name: density_1997_2004_Fall_0m would indicate that this water density raster was interpolated using data from 1997-2004 for the fall at 0 meters (or the surface). The seasons were defined using the same months as the remote sensing data--namely, Fall = September, October, November; Winter = December, January, February; Spring = March, April, May; and Summer = June, July, August. The accuracies of these interpolated surfaces were calculated by validating with 25% of the water density points that were previously set aside. These control points are located in the personal geodatabase named Water_Stratification_Points.

The data source file is a 10-layered GeoTIFF file, derived from the raster data source GRTSmaster_habitats (link). Both GeoTIFFs (GRTSmaster_habitats, GRTSmh_brick) use the INT4S datatype. The GRTSmh_brick data source (resolution 32 m) holds the decimal integer ranking numbers of 10 hierarchical levels of the GRTS cell addresses, including the one from GRTSmaster_habitats (with GRTS cell addresses at the resolution level).

See R-code in the GitHub repository 'n2khab-preprocessing' at commit ecadaf5 for its creation from the GRTSmaster_habitats data source.

A reading function to return the data source in a standardized way into the R environment is provided by the R-package n2khab.

The higher-level ranking numbers of the RasterBrick allow spatially balanced samples at lower spatial resolution than that of 32 m, and can also be used for aggregation purposes. The provided hierarchical levels correspond to the resolutions vector 32 * 2^(0:9) (minimum: 32 meters, maximum: 16384 meters).

Beware that not all GRTS ranking numbers are present in the data source, as the original GRTS raster has been clipped with the Flemish outer borders (i.e., not excluding the Brussels Capital Region).

Wadi Hasa Sample Dataset — GRASS GIS Location
Version 1.0 (2025-09-19)

Overview
--------
This archive contains a complete GRASS GIS *Location* for the Wadi Hasa region (Jordan), including base data and exemplar analyses used in the Geomorphometry chapter. It is intended for teaching and reproducible research in archaeological GIS.

How to use
----------
1) Unzip the archive into your GRASSDATA directory (or a working folder) and add the Location to your GRASS session.
2) Start GRASS and open the included workspace (Workspace.gxw) or choose a Mapset to work in.
3) Set the computational region to the default extent/resolution for reproducibility:
g.region n=3444220 s=3405490 e=796210 w=733450 nsres=30 ewres=30 -p
4) Inspect layers as needed:
g.list type=rast,vector
r.info

Citation & License
------------------
Please cite this dataset as:

Isaac I. Ullah. 2025. *Wadi Hasa Sample Dataset (GRASS GIS Location)*. Zenodo. https://doi.org/10.5281/zenodo.17162040

All contents are released under the Creative Commons Attribution 4.0 International (CC BY 4.0) license. The original Wadi Hasa survey dataset is available at: https://figshare.com/articles/dataset/Wadi_Hasa_Ancient_Pastoralism_Project/1404216 The original Wadi Hasa survey dataset is available at: https://figshare.com/articles/dataset/Wadi_Hasa_Ancient_Pastoralism_Project/1404216

Coordinate Reference System
---------------------------
- Projection: UTM, Zone 36N
- Datum/Ellipsoid: WGS84
- Units: meter
- Coordinate system and units are defined in the GRASS Location (PROJ_INFO/UNITS).

Default Region (computational extent & resolution)
--------------------------------------------------
- North: 3444220
- South: 3405490
- East: 796210
- West: 733450
- Resolution: 30 (NS), 30 (EW)
- Rows x Cols: 1291 x 2092 (cells: 2700772)

Directory / Mapset Structure
----------------------------
This Location contains the following Mapsets (data subprojects), each with its own raster/vector layers and attribute tables (SQLite):
- Boolean_Predictive_Modeling: 8 raster(s), 4 vector(s)
- ISRIC_soilgrid: 31 raster(s), 0 vector(s)
- Landsat_Imagery: 3 raster(s), 0 vector(s)
- Landscape_Evolution_Modeling: 41 raster(s), 0 vector(s)
- Least_Cost_Analysis: 13 raster(s), 4 vector(s)
- Machine_Learning_Predictive_Modeling: 70 raster(s), 11 vector(s)
- PERMANENT: 4 raster(s), 2 vector(s)
- Sentinel2_Imagery: 4 raster(s), 0 vector(s)
- Site_Buffer_Analysis: 0 raster(s), 2 vector(s)
- Terrain_Analysis: 27 raster(s), 2 vector(s)
- Territory_Modeling: 14 raster(s), 2 vector(s)
- Trace21k_Paleoclimate_Downscale_Example: 4 raster(s), 2 vector(s)
- Visibility_Analysis: 11 raster(s), 5 vector(s)

Data Content (summary)
----------------------
- Total raster maps: 230
- Total vector maps: 34

Raster resolutions present:
- 10 m: 13 raster(s)
- 30 m: 183 raster(s)
- 208.01 m: 2 raster(s)
- 232.42 m: 30 raster(s)
- 1000 m: 2 raster(s)

Major content themes include:
- Base elevation surfaces and terrain derivatives (e.g., DEMs, slope, aspect, curvature, flow accumulation, prominence).
- Hydrology, watershed, and stream-related layers.
- Visibility analyses (viewsheds; cumulative viewshed analyses for Nabataean and Roman towers).
- Movement and cost-surface analyses (isotropic/anisotropic costs, least-cost paths, time-to-travel surfaces).
- Predictive modeling outputs (boolean/inductive/deductive; regression/classification surfaces; training/test rasters).
- Satellite imagery products (Landsat NIR/RED/NDVI; Sentinel‑2 bands and RGB composite).
- Soil and surficial properties (ISRIC SoilGrids 250 m products).
- Paleoclimate downscaling examples (CHELSA TraCE21k MAT/AP).

Vectors include:
- Archaeological point datasets (e.g., WHS_sites, WHNBS_sites, Nabatean_Towers, Roman_Towers).
- Derived training/testing samples and buffer polygons for modeling.
- Stream network and paths from least-cost analyses.

Important notes & caveats
-------------------------
- Mixed resolutions: Analyses span 10 m (e.g., Sentinel‑2 composites, some derived surfaces), 30 m (majority of terrain and modeling rasters), ~232 m (SoilGrids products), and 1 km (CHELSA paleoclimate). Set the computational region appropriately (g.region) before processing or visualization.
- NoData handling: The raw SRTM import (Hasa_30m_SRTM) reports extreme min/max values caused by nodata placeholders. Use the clipped/processed DEMs (e.g., Hasa_30m_clipped_wshed*) and/or set nodata with r.null as needed.
- Masks: MASK rasters are provided for analysis subdomains where relevant.
- Attribute tables: Vector attribute data are stored in per‑Mapset SQLite databases (sqlite/sqlite.db) and connected via layer=1.

Provenance (brief)
------------------
- Primary survey points and site datasets derive from the Wadi Hasa projects (see Figshare record above).
- Base elevation and terrain derivatives are built from SRTM and subsequently processed/clipped for the watershed.
- Soil variables originate from ISRIC SoilGrids (~250 m).
- Paleoclimate examples use CHELSA TraCE21k surfaces (1 km) that are interpolated to higher resolutions for demonstration.
- Satellite imagery layers are derived from Landsat and Sentinel‑2 scenes.

Reproducibility & quick commands
--------------------------------
- Restore default region: g.region n=3444220 s=3405490 e=796210 w=733450 nsres=30 ewres=30 -p
- Set region to a raster: g.region raster=

Change log
----------
- v1.0: Initial public release of the teaching Location on Zenodo (CC BY 4.0).

Contact
-------
For questions, corrections, or suggestions, please contact Isaac I. Ullah