A continuous dataset of Land Surface Temperature (LST) is vital for climatological and environmental studies. LST can be regarded as a combination of seasonal mean temperature (climatology) and daily anomaly, which is attributed mainly to the synoptic-scale atmospheric circulation (weather). To reproduce LST in cloudy pixels, time series (2002-2019) of cloud-free 1km MODIS Aqua LST images were generated and the pixel-based seasonality (climatology) was calculated using temporal Fourier analysis. To add the anomaly, we used the NCEP Climate Forecast System Version 2 (CFSv2) model, which provides air surface temperature under both cloudy and clear sky conditions. The combination of the two sources of data enables the estimation of LST in cloudy pixels.

Data structure

The dataset consists of geo-located continuous LST (Day, Night and Daily) which calculates LST values of cloudy pixels. The spatial domain of the data is the Eastern Mediterranean, at the resolution of the MYD11A1 product (~1 Km). Data are stored in GeoTIFF format as signed 16-bit integers using a scale factor of 0.02, with one file per day, each defined by 4 dimensions (Night LST Cont., Day LST Cont., Daily Average LST Cont., QA). The QA band stores information about the presence of cloud in the original pixel. If in both original files, Day LST and Night LST there was NoData due to clouds, then the QA value is 0. QA value of 1 indicates NoData at original Day LST, 2 indicates NoData at Night LST and 3 indicates valid data at both, day and night. File names follow this naming convention: LST_ 

This dataset contains both large (A0) printable maps of the Torres Strait broken into six overlapping regions, based on a clear sky, clear water composite Sentinel 2 composite imagery and the imagery used to create these maps. These maps show satellite imagery of the region, overlaid with reef and island boundaries and names. Not all features are named, just the more prominent features. This also includes a vector map of Ashmore Reef and Boot Reef in Coral Sea as these were used in the same discussions that these maps were developed for. The map of Ashmore Reef includes the atoll platform, reef boundaries and depth polygons for 5 m and 10 m.

This dataset contains all working files used in the development of these maps. This includes all a copy of all the source datasets and all derived satellite image tiles and QGIS files used to create the maps. This includes cloud free Sentinel 2 composite imagery of the Torres Strait region with alpha blended edges to allow the creation of a smooth high resolution basemap of the region.

The base imagery is similar to the older base imagery dataset: Torres Strait clear sky, clear water Landsat 5 satellite composite (NERP TE 13.1 eAtlas, AIMS, source: NASA).

Most of the imagery in the composite imagery from 2017 - 2021.

Method: The Sentinel 2 basemap was produced by processing imagery from the World_AIMS_Marine-satellite-imagery dataset (not yet published) for the Torres Strait region. The TrueColour imagery for the scenes covering the mapped area were downloaded. Both the reference 1 imagery (R1) and reference 2 imagery (R2) was copied for processing. R1 imagery contains the lowest noise, most cloud free imagery, while R2 contains the next best set of imagery. Both R1 and R2 are typically composite images from multiple dates.

The R2 images were selectively blended using manually created masks with the R1 images. This was done to get the best combination of both images and typically resulted in a reduction in some of the cloud artefacts in the R1 images. The mask creation and previewing of the blending was performed in Photoshop. The created masks were saved in 01-data/R2-R1-masks. To help with the blending of neighbouring images a feathered alpha channel was added to the imagery. The processing of the merging (using the masks) and the creation of the feathered borders on the images was performed using a Python script (src/local/03-merge-R2-R1-images.py) using the Pillow library and GDAL. The neighbouring image blending mask was created by applying a blurring of the original hard image mask. This allowed neighbouring image tiles to merge together.

The imagery and reference datasets (reef boundaries, EEZ) were loaded into QGIS for the creation of the printable maps.

To optimise the matching of the resulting map slight brightness adjustments were applied to each scene tile to match its neighbours. This was done in the setup of each image in QGIS. This adjustment was imperfect as each tile was made from a different combinations of days (to remove clouds) resulting in each scene having a different tonal gradients across the scene then its neighbours. Additionally Sentinel 2 has slight stripes (at 13 degrees off the vertical) due to the swath of each sensor having a slight sensitivity difference. This effect was uncorrected in this imagery.

Single merged composite GeoTiff: The image tiles with alpha blended edges work well in QGIS, but not in ArcGIS Pro. To allow this imagery to be used across tools that don't support the alpha blending we merged and flattened the tiles into a single large GeoTiff with no alpha channel. This was done by rendering the map created in QGIS into a single large image. This was done in multiple steps to make the process manageable.

The rendered map was cut into twenty 1 x 1 degree georeferenced PNG images using the Atlas feature of QGIS. This process baked in the alpha blending across neighbouring Sentinel 2 scenes. The PNG images were then merged back into a large GeoTiff image using GDAL (via QGIS), removing the alpha channel. The brightness of the image was adjusted so that the darkest pixels in the image were 1, saving the value 0 for nodata masking and the boundary was clipped, using a polygon boundary, to trim off the outer feathering. The image was then optimised for performance by using internal tiling and adding overviews. A full breakdown of these steps is provided in the README.md in the 'Browse and download all data files' link.

The merged final image is available in export\TS_AIMS_Torres Strait-Sentinel-2_Composite.tif.

Change Log: 2023-03-02: Eric Lawrey Created a merged version of the satellite imagery, with no alpha blending so that it can be used in ArcGIS Pro. It is now a single large GeoTiff image. The Google Earth Engine source code for the World_AIMS_Marine-satellite-imagery was included to improve the reproducibility and provenance of the dataset, along with a calculation of the distribution of image dates that went into the final composite image. A WMS service for the imagery was also setup and linked to from the metadata. A cross reference to the older Torres Strait clear sky clear water Landsat composite imagery was also added to the record.

22 Nov 2023: Eric Lawrey Added the data and maps for close up of Mer. - 01-data/TS_DNRM_Mer-aerial-imagery/ - preview/Torres-Strait-Mer-Map-Landscape-A0.jpeg - exports/Torres-Strait-Mer-Map-Landscape-A0.pdf Updated 02-Torres-Strait-regional-maps.qgz to include the layout for the new map.

Source datasets: Complete Great Barrier Reef (GBR) Island and Reef Feature boundaries including Torres Strait Version 1b (NESP TWQ 3.13, AIMS, TSRA, GBRMPA), https://eatlas.org.au/data/uuid/d2396b2c-68d4-4f4b-aab0-52f7bc4a81f5

Geoscience Australia (2014b), Seas and Submerged Lands Act 1973 - Australian Maritime Boundaries 2014a - Geodatabase [Dataset]. Canberra, Australia: Author. https://creativecommons.org/licenses/by/4.0/ [license]. Sourced on 12 July 2017, https://dx.doi.org/10.4225/25/5539DFE87D895

Basemap/AU_GA_AMB_2014a/Exclusive_Economic_Zone_AMB2014a_Limit.shp The original data was obtained from GA (Geoscience Australia, 2014a). The Geodatabase was loaded in ArcMap. The Exclusive_Economic_Zone_AMB2014a_Limit layer was loaded and exported as a shapefile. Since this file was small no clipping was applied to the data.

Geoscience Australia (2014a), Treaties - Australian Maritime Boundaries (AMB) 2014a [Dataset]. Canberra, Australia: Author. https://creativecommons.org/licenses/by/4.0/ [license]. Sourced on 12 July 2017, http://dx.doi.org/10.4225/25/5539E01878302 Basemap/AU_GA_Treaties-AMB_2014a/Papua_New_Guinea_TSPZ_AMB2014a_Limit.shp The original data was obtained from GA (Geoscience Australia, 2014b). The Geodatabase was loaded in ArcMap. The Papua_New_Guinea_TSPZ_AMB2014a_Limit layer was loaded and exported as a shapefile. Since this file was small no clipping was applied to the data.

AIMS Coral Sea Features (2022) - DRAFT This is a draft version of this dataset. The region for Ashmore and Boot reef was checked. The attributes in these datasets haven't been cleaned up. Note these files should not be considered finalised and are only suitable for maps around Ashmore Reef. Please source an updated version of this dataset for any other purpose. CS_AIMS_Coral-Sea-Features/CS_Names/Names.shp CS_AIMS_Coral-Sea-Features/CS_Platform_adj/CS_Platform.shp CS_AIMS_Coral-Sea-Features/CS_Reef_Boundaries_adj/CS_Reef_Boundaries.shp CS_AIMS_Coral-Sea-Features/CS_Depth/CS_AIMS_Coral-Sea-Features_Img_S2_R1_Depth5m_Coral-Sea.shp CS_AIMS_Coral-Sea-Features/CS_Depth/CS_AIMS_Coral-Sea-Features_Img_S2_R1_Depth10m_Coral-Sea.shp

Murray Island 20 Sept 2011 15cm SISP aerial imagery, Queensland Spatial Imagery Services Program, Department of Resources, Queensland This is the high resolution imagery used to create the map of Mer.

Marine satellite imagery (Sentinel 2 and Landsat 8) (AIMS), https://eatlas.org.au/data/uuid/5d67aa4d-a983-45d0-8cc1-187596fa9c0c - World_AIMS_Marine-satellite-imagery

Data Location: This dataset is filed in the eAtlas enduring data repository at: data\custodian\2020-2029-AIMS\TS_AIMS_Torres-Strait-Sentinel-2-regional-maps. On the eAtlas server it is stored at eAtlas GeoServer\data\2020-2029-AIMS.

Replication code and data for the paper "Satellite observations reveal inequalities in the progress and effectiveness of recent electrification in sub-Saharan Africa" published in One Earth (DOI: 10.1016/j.oneear.2020.03.007)

This repository hosts:

A JavaScript file to process remotely-sensed data into Google Earth Engine (step 1)

A R script, to be run after the successful completion of the Google Earth Engine processing (step 2)

Supporting files to run the analysis (e.g. a shapefile of provinces, validation data, etc.)

Create a Google account, if you do not have one, and require access to Earth Engine https://signup.earthengine.google.com.

Make sure your Google Drive has enough cloud storage space available.

Clone the repository.

Run the JavaScript file in Google Earth Engine and wait that the data processing is complete (can take >24 hours)

Run the R script, which will reproduce the analysis and the figures contained in the paper.

Open the QGIS project files to replicate maps with the appropriate layout.

Source code-related issues should be opened directly on GitHub. Broader questions of the methods should be addressed to giacomo.falchetta@feem.it

Urban Tree Canopy Assessment. This was created using the Urban Tree Canopy Syracuse 2010 (All Layers) file HERE.The data for this map was created using LIDAR and other spatial analysis tools to identify and measure tree canopy in the landscape. This was a collaboration between the US Forest Service Northern Research Station (USFS), the University of Vermont Spatial Laboratory, and SUNY ESF. Because the full map is too large to be viewed in ArcGIS Online, this has been reduced to a vector tile layer to allow it to be viewed online. To download and view the shapefiles and all of the layers, you can download the data HERE and view this in either ArcGIS Pro or QGIS.Data DictionaryDescription source  USDA Forest ServiceList of values  Value 1 Description Tree CanopyValue 2 Description Grass/ShrubValue 3 Description Bare SoilValue 4 Description WaterValue 5 Description BuildingsValue 6 Description Roads/RailroadsValue 7 Description Other PavedField Class Alias Class Data type String Width 20Geometric objects  Feature class name landcover_2010_syracusecity Object type  complex Object count 7ArcGIS Feature Class Properties Feature class name landcover_2010_syracusecity Feature type  Simple Geometry type Polygon Has topology FALSE Feature count 7 Spatial index TRUE Linear referencing  FALSEDistributionAvailable format  Name ShapefileTransfer options  Transfer size 163.805Description Downloadable DataFieldsDetails for object landcover_2010_syracusecityType Feature Class Row count  7 Definition  UTCField FIDAlias FID Data type OID Width  4 Precision 0 Scale 0Field descriptionInternal feature number.Description source ESRIDescription of valueSequential unique whole numbers that are automatically generated.Field ShapeAlias Shape Data type Geometry Width 0 Precision 0 Scale 0Field description Feature geometry.Description source  ESRIDescription of values Coordinates defining the features.Field CodeAlias Code Data type Number Width 4Overview Description  Metadata DetailsMetadata language  English Metadata character set utf8 - 8 bit UCS Transfer FormatScope of the data described by the metadata  dataset Scope name  datasetLast update 2011-06-02ArcGIS metadata properties Metadata format ArcGIS 1.0 Metadata style North American Profile of ISO19115 2003Created in ArcGIS for the item 2011-06-02 16:48:35 Last modified in ArcGIS for the item 2011-06-02 16:44:43Automatic updates Have been performed Yes Last update 2011-06-02 16:44:43Item location history  Item copied or moved 2011-06-02 16:48:35 From T:\TestSites\NY\Syracuse\Temp\landcover_2010_syracusecity To \T7500\F$\Export\LandCover_2010_SyracuseCity\landcover_2010_syracusecity

The dataset is available for download in shapefile format and can be viewed in Geographic Information Systems(GIS) such as ArcMap, QGIS, or Google Earth (Pro).The data is available for all of Zambia. It has the following attributes: Name, Original Name, Type, Sub Type, Source, Province (Code), District (Code), Ward (Code), Constituency (Code), Global ID, LAT, LONG

A Google Earth Engine implementation of the Floodwater Depth Estimation Tool (FwDET) This is a Google Earth Engine implementation of the Floodwater Depth Estimation Tool (FwDET) developed by the Surface Dynamics and Modeling Lab at the University of Alabama that calculates flood depth using a flood extent layer and a digital elevation model. This research is made possible by the CyberSeed Program at the University of Alabama. Project name: WaterServ: A Cyberinfrastructure for Analysis, Visualization and Sharing of Hydrological Data. Please see the associated publications: 1. Peter, B.G., Cohen, S., Lucey, R., Munasinghe, D., Raney, A. and Brakenridge, G.R., 2020. Google Earth Engine Implementation of the Floodwater Depth Estimation Tool (FwDET-GEE) for rapid and large scale flood analysis. IEEE Geoscience and Remote Sensing Letters, 19, pp.1-5. https://ieeexplore.ieee.org/abstract/document/9242297 2. Cohen, S., Peter, B.G., Haag, A., Munasinghe, D., Moragoda, N., Narayanan, A. and May, S., 2022. Sensitivity of remote sensing floodwater depth calculation to boundary filtering and digital elevation model selections. Remote Sensing, 14(21), p.5313. https://github.com/csdms-contrib/fwdet 3. Cohen, S., A. Raney, D. Munasinghe, J.D. Loftis J, A. Molthan, J. Bell, L. Rogers, J. Galantowicz, G.R. Brakenridge7, A.J. Kettner, Y. Huang, Y. Tsang, (2019). The Floodwater Depth Estimation Tool (FwDET v2.0) for Improved Remote Sensing Analysis of Coastal Flooding. Natural Hazards and Earth System Sciences, 19, 2053–2065. https://doi.org/10.5194/nhess-19-2053-2019 4. Cohen, S., G. R. Brakenridge, A. Kettner, B. Bates, J. Nelson, R. McDonald, Y. Huang, D. Munasinghe, and J. Zhang (2018), Estimating Floodwater Depths from Flood Inundation Maps and Topography, Journal of the American Water Resources Association, 54 (4), 847–858. https://doi.org/10.1111/1752-1688.12609 Sample products and data availability: https://sdml.ua.edu/models/fwdet/ https://sdml.ua.edu/michigan-flood-may-2020/ https://cartoscience.users.earthengine.app/view/fwdet-gee-mi https://alabama.app.box.com/s/31p8pdh6ngwqnbcgzlhyk2gkbsd2elq0 GEE implementation output: fwdet_gee_brazos.tif ArcMap implementation output (see Cohen et al. 2019): fwdet_v2_brazos.tif iRIC validation layer (see Nelson et al. 2010): iric_brazos_hydraulic_model_validation.tif Brazos River inundation polygon access in GEE: var brazos = ee.FeatureCollection('users/cartoscience/FwDET-GEE-Public/Brazos_River_Inundation_2016') Nelson, J.M., Shimizu, Y., Takebayashi, H. and McDonald, R.R., 2010. The international river interface cooperative: public domain software for river modeling. In 2nd Joint Federal Interagency Conference, Las Vegas, June (Vol. 27). Google Earth Engine Code /* ---------------------------------------------------------------------------------------------------------------------- # FwDET-GEE calculates floodwater depth from a floodwater extent layer and a DEM Authors: Brad G. Peter, Sagy Cohen, Ronan Lucey, Dinuke Munasinghe, Austin Raney Emails: bpeter@ua.edu, sagy.cohen@ua.edu, ronan.m.lucey@nasa.gov, dsmunasinghe@crimson.ua.edu, aaraney@crimson.ua.edu Organizations: BP, SC, DM, AR - University of Alabama; RL - University of Alabama in Huntsville Last Modified: 10/08/2020 To cite this code use: Peter, Brad; Cohen, Sagy; Lucey, Ronan; Munasinghe, Dinuke; Raney, Austin, 2020, "A Google Earth Engine implementation of the Floodwater Depth Estimation Tool (FwDET-GEE)", https://doi.org/10.7910/DVN/JQ4BCN, Harvard Dataverse, V2 ------------------------------------------------------------------------------------------------------------------------- This is a Google Earth Engine implementation of the Floodwater Depth Estimation Tool (FwDETv2.0) [1] developed by the Surface Dynamics and Modeling Lab at the University of Alabama that calculates flood depth using a flood extent layer and a digital elevation model. This research is made possible by the CyberSeed Program at the University of Alabama. Project name: WaterServ: A Cyberinfrastructure for Analysis, Visualization and Sharing of Hydrological Data. GitHub Repository (ArcMap and QGIS implementations): https://github.com/csdms-contrib/fwdet ------------------------------------------------------------------------------------------------------------------------- How to run this code with your flood extent GEE asset: User of this script will need to update path to flood extent (line 32 or 33) and select from the processing options. Available DEM options (1) are USGS/NED (U.S.) and USGS/SRTMGL1_003 (global). Other options include (2) running the elevation outlier filtering algorithm, (3) adding water body data to the inundation extent, (4) add a water body data layer uploaded by the user rather than using the JRC global surface water data, (5) masking out regular water body data, (6) masking out 0 m depths, (7) choosing whether or not to export, (8) exporting additional data layers, and (9) setting an export file name....

Contenu Carte de chaque département extrait d'Open Street Map, mise à jour chaque semaine. NB : Les régions sont également disponibles. Chaque département est livré sous forme d'une archive ZIP qui contient plusieurs couches cartographiques au fomat shapefile (le .doc de la cartographie) : places.shp : noms des villes ou des quartiers roads.shp : toutes les voies de passage de l'autoroute au chemin piéton buildings.shp : l'espace bâti raillways.shp : les voies ferrées waterways.shp :le réseau hydrolique points.shp : une liste de point d’intérêt natural.shp : zones vertes landuse.shp : occupation des sol admin-departement.shp : le département Par ailleurs, un fichier projet QGis très sommaire est fourni dans l'archive, afin de visualiser la superposition des couches dans un outil libre. Origine Les données proviennent de la base de données cartographique communautaire et libre OpenStreetMap. Le découpage par département provient du Contours des départements français issus d'OpenStreetMap. Les shapefile sont extraits selon la méthode exposée par l'excellent article de Maxime Résibois sur PortailSIG : http://www.portailsig.org/content/recuperer-des-donnees-openstreetmap-gdalogr Les sources du traitement automatique d'extraction sont disponibles sur github. Elles s'appuyent sur tuttle, un système de build pour les données. Licence Ces données sont issues du crowdsourcing effectué par les contributeurs au projet OpenStreetMap et sont sous licence ODbL qui impose un partage à l'identique et la mention obligatoire d'attribution doit être "© les contributeurs d'OpenStreetMap sous licence ODbL" conformément à http://osm.org/copyright Historique des modifications 7 avril 2018 correction d'un bug qui pouvait retirer une partie de la donnée sur les départements côtiers mise à jour du fichier QGis pour que la carte soit plus jolie de près Départements et covid Si votre département est soumis au pass sanitaire, commandez le vôtre au format carte bancaire sur carte-sanitaire.fr

The "NSDI Zambia Operational Health Facility Layer, Version 01 (Beta)" provides health facility and health affiliated infrastructure point locations, names, types, and source of the data. The dataset was developed by compiling and standardizing existing government data sources of health facility and affiliated infrastructure locations and names data from the Ministry of Health (MoH) obtained in 2019 and from the 2010 census cartography from Zambia Statistics Agency (ZamStats). The dataset is available for download in shapefile format and can be viewed in Geographic Information Systems(GIS) such as ArcMap, QGIS, or Google Earth (Pro). The data is available for all of Zambia. It has the following attributes: Name, Original Name (from original dataset), Type, Sub Type, Source, Province (Code), District (Code), Global ID. The dataset also includes a Label column which can be used for labeling.For more information about the settlement data and methodology, see the data release notes here.

The "NSDI Zambia Operational Points of Interest, Version 01 (Beta)" provides a set of points of interest locations, categorized by type and theme, to spatially locate, identify, and visualize points of interest nationwide. The dataset was developed by compiling and standardizing existing data from 2010 census cartography from Zambia Statistics Agency (ZamStats), and Community Led Total Sanitation (CLTS) data set from The Ministry of Water Development, Sanitation and Environmental Protection (MWDSEP).The dataset is available for download in shapefile format and can be viewed in Geographic Information Systems(GIS) such as ArcMap, QGIS, or Google Earth (Pro). The data is available for all of Zambia. It has the following attributes: Name, Original Name (from original dataset), Type, Sub Type, Source, Province (Code), District (Code), Ward (Code), Constituency (Code), Global ID.

Accurate coastal wave and hydrodynamic modelling relies on quality bathymetric input. Many national scale modelling studies, hindcast and forecast products, have, or are currently using a 2009 digital elevation model (DEM), which does not include recently available bathymetric surveys and is now out of date. There are immediate needs for an updated national product, preceding the delivery of the AusSeabed program’s Global Multi-Resolution Topography for Australian coastal and ocean models. There are also challenges in stitching coarse resolution DEMs, which are often too shallow where they meet high-resolution information (e.g. LiDAR surveys) and require supervised/manual modifications (e.g. NSW, Perth, and Portland VIC bathymetries). This report updates the 2009 topography and bathymetry with a selection of nearshore surveys and demonstrates where the 2009 dataset and nearshore bathymetries do not matchup. Lineage: All of the datasets listed in Table 1 (see supporting files) were used in previous CSIRO internal projects or download from online data portals and processed using QGIS and R’s ‘raster’ package. The Perth LiDAR surveys were provided as points and gridded in R using raster::rasterFromXYZ(). The Macquarie Harbour contour lines were regridded in QGIS using the TIN interpolator. Each dataset was mapped with an accompanying Type Identifier (TID) following the conventions of the GEBCO dataset. The mapping went through several iterations, at each iteration the blending was checked for inconstancy, i.e., where the GA250m DEM was too shallow when it met the high-resolution LiDAR surveys. QGIS v3.16.4 was used to draw masks over inconstant blending and GA250 values falling within the mask and between two depths were assigned NA (no-data). LiDAR datasets were projected to +proj=longlat +datum=WGS84 +no_defs using raster::projectRaster(), resampled to the GA250 grid using raster::resample() and then merged with raster::merge(). Nearest neighbour resampling was performed for all datasets except for GEBCO ~500m product, which used the bilinear method. The order of the mapping overlay is sequential from TID = 1 being the base, through to 107, where 0 is the gap filled values.

Permissions are required for all code and internal datasets (Contact Julian OGrady).

Introduction

We are enclosing the database used in our research titled "Concentration and Geospatial Modelling of Health Development Offices' Accessibility for the Total and Elderly Populations in Hungary", along with our statistical calculations. For the sake of reproducibility, further information can be found in the file Short_Description_of_Data_Analysis.pdf and Statistical_formulas.pdf

The sharing of data is part of our aim to strengthen the base of our scientific research. As of March 7, 2024, the detailed submission and analysis of our research findings to a scientific journal has not yet been completed.

Short Description of Data Analysis and Attached Files (datasets):

Our research utilised data from 2022, serving as the basis for statistical standardisation. The 2022 Hungarian census provided an objective basis for our analysis, with age group data available at the county level from the Hungarian Central Statistical Office (KSH) website. The 2022 demographic data provided an accurate picture compared to the data available from the 2023 microcensus. The used calculation is based on our standardisation of the 2022 data. For xlsx files, we used MS Excel 2019 (version: 1808, build: 10406.20006) with the SOLVER add-in.

Hungarian Central Statistical Office served as the data source for population by age group, county, and regions: https://www.ksh.hu/stadat_files/nep/hu/nep0035.html, (accessed 04 Jan. 2024.) with data recorded in MS Excel in the Data_of_demography.xlsx file.

In 2022, 108 Health Development Offices (HDOs) were operational, and it's noteworthy that no developments have occurred in this area since 2022. The availability of these offices and the demographic data from the Central Statistical Office in Hungary are considered public interest data, freely usable for research purposes without requiring permission.

The contact details for the Health Development Offices were sourced from the following page (Hungarian National Population Centre (NNK)): https://www.nnk.gov.hu/index.php/efi (n=107). The Semmelweis University Health Development Centre was not listed by NNK, hence it was separately recorded as the 108th HDO. More information about the office can be found here: https://semmelweis.hu/egeszsegfejlesztes/en/ (n=1). (accessed 05 Dec. 2023.)

Geocoordinates were determined using Google Maps (N=108): https://www.google.com/maps. (Accessed 02 Jan. 2024.) Recording of geocoordinates (latitude and longitude according to WGS 84 standard), address data (postal code, town name, street, and house number), and the name of each HDO was carried out in the: Geo_coordinates_and_names_of_Hungarian_Health_Development_Offices.csv file.

The foundational software for geospatial modelling and display, QGIS 3.34, an open-source software, can be downloaded from: https://qgis.org/en/site/forusers/download.html. (accessed 04 Jan. 2024.)

The EFI.qgz QGIS project file contains Hungary's administrative map and the recorded addresses of the HDOs from the Geo_coordinates_and_names_of_Hungarian_Health_Development_Offices.csv file, imported via .csv file.

The OpenStreetMap tileset is directly accessible from www.openstreetmap.org in QGIS. (accessed 04 Jan. 2024.)

A brief description of the statistical formulas applied is included in the Statistical_formulas.pdf.

Recording of our base data for statistical concentration and diversification measurement was done using MS Excel 2019 (version: 1808, build: 10406.20006) in .xlsx format.

• Aggregated number of HDOs by county: Number_of_HDOs.xlsx
• Standardised data (Number of HDOs per 100,000 residents): Standardized_data.xlsx
• Calculation of the Lorenz curve: Lorenz_curve.xlsx
• Calculation of the Gini index: Gini_Index.xlsx
• Calculation of the LQ index: LQ_Index.xlsx
• Calculation of the Herfindahl-Hirschman Index: Herfindahl_Hirschman_Index.xlsx
• Calculation of the Entropy index: Entropy_Index.xlsx
• Regression and correlation analysis calculation: Regression_correlation.xlsx

The translation of these supplementary files into English was completed on 1st Mar. 2024.

If you have any further questions regarding the dataset, please contact the corresponding author: domjan.peter@phd.semmelweis.hu

Here are the results in a paper entitled "Characterization of the 2008 phreatomagmatic eruption of Okmok from ArcticDEM and InSAR: deposition, erosion, and deformation" submitted to JGR Solid Earth in 2020.

The main revision compared to version 1: This revision does not use one DEM (acquired on 15 May 2016) that was partly contaminated by clouds in the north flank of Ahmanilix. This revision mostly improves the result of the elevation change rate (rate.tif), but it also slightly changes the elevation change data and its corresponding uncertainties.

It includes the 2-m resolution surface elevation change of the 2008 Okmok eruption (Fig. 3a in the paper) and the 2-m resolution post-eruptive elevation change rate map (Fig. 4), as well as the corresponding uncertainties (Fig. S3). It also includes the boundary of the proximal deposit field classified using a minimum elevation increase of 2 m, the boundary of large slope failure, and the shorelines of two lakes (Fig. 3a and S5) at different acquisition times.

The GeoTIFF files can be viewed in free and open-source software QGIS, in Google Earth, or by Matlab using code https://github.com/ihowat/setsm_postprocessing/blob/master/readGeotiff.m. The shapefiles can be viewed in QGIS. Google Earth may not show some of the shapefiles well.

ps-places-metadata-v1.01

SUMMARY

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

RATIONALE

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

METHODOLOGY

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

PROJECTION

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

ATTRIBUTES

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

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

LICENSE

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

Peter Scott 16/6/2011

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

The rivers of Central America dataset is derived from the World Wildlife Fund's (WWF) HydroSHEDS drainage direction layer and a stream network layer. The source of the drainage direction layer was the 15-second Digital Elevation Model (DEM) from NASA's Shuttle Radar Topographic Mission (SRTM). The raster stream network was determined by using the HydroSHEDS flow accumulation grid, with a threshold of about 1000 km² upstream area.

The stream network dataset consists of the following information: the origin node of each arc in the network (FROM_NODE), the destination of each arc in the network (TO_NODE), the Strahler stream order of each arc in the network (STRAHLER), numerical code and name of the major basin that the arc falls within (MAJ_BAS and MAJ_NAME); - area of the major basin in square km that the arc falls within (MAJ_AREA); - numerical code and name of the sub-basin that the arc falls within (SUB_BAS and SUB_NAME); - area of the sub-basin in square km that the arc falls within (SUB_AREA); - numerical code of the sub-basin towards which the sub-basin flows that the arc falls within (TO_SUBBAS) (the codes -888 and -999 have been assigned respectively to internal sub-basins and to sub-basins draining into the sea). The attributes table now includes a field named "Regime" with tentative classification of perennial ("P") and intermittent ("I") streams.

Supplemental Information:

This dataset is developed as part of a GIS-based information system on water resources for the Central American continent. It has been published in the framework of the AQUASTAT - programme of the Land and Water Division of the Food and Agriculture Organization of the United Nations.

Contact points:

Metadata contact: AQUASTAT FAO-UN Land and Water Division

Contact: Jippe Hoogeveen FAO-UN Land and Water Division

Data lineage:

The linework of the map was obtained by converting the stream network to a feature dataset with the Hydrology toolset in ESRI ArcGIS.The Flow Direction and Stream Order grids were derived from hydrologically corrected elevation data with a resolution of 15 arc-seconds.The elevation dataset was part of a mapping product, HydroSHEDS, developed by the Conservation Science Program of World Wildlife Fund.Original input data had been obtained during NASA's Shuttle Radar Topography Mission (SRTM).

Online resources:

Download - Rivers of Central America (ESRI shapefile)

General information regarding the HydroSHEDS data product

HydroSHEDS dataset download and technical information

This dataset contains georeferenced data of forestry roads and sediment connectivity in the Purapel catchment, which drains the Chilean Coastal Range. The forestry road network consists of all the dirt and gravel roads mapped in QGIS by observing open satellite images and vectorial data available during January 2021. The observed data are maps that were listed in the QGIS OpenLayers plugin (https://github.com/sourcepole/qgis-openlayers-plugin), such as Google Satellite (Map data ©2015 Google) and OpenStreetMap ¹, the road network of the Chilean Congress National Library (https://www.bcn.cl/siit/mapas_vectoriales) and compositions of Sentinel 2 images (European Space Agency, courtesy of the U.S. Geological Survey) of the post-2017 fire period.

Sediment Connectivity maps were calculated on a 5 m resolution LiDAR DTM using the Connectivity Index ². The maps were derived from the stand-alone, free and open-source executable SedInConnect 2.3 ³ using the Weighting factor of ² and two different targets, which are available as tif files:

• ICs.tif contains IC_s, the Connectivity Index to the stream network.
• ICrs.tif contains ICr_s, the Connectivity Index to the road and the stream network.

Here, the Road Connectivity, RC (dimensionless) is defined as the difference between both previous maps, with the aim to describe the change in sediment connectivity due to forestry road network:

• RC = IC_rs - IC_s

It is available as RC.tif file. The area of high RC was defined using the percentile 95 (3.12). File RC95.tif is a mask of RC ≥ 3.12.

The contributing area CA (m²) was calculated using the multiple flow D-infinity approach ⁴ using TauDEM (https://hydrology.usu.edu/taudem/taudem5/downloads.html).

The file CA_RC95.tif contains the contributing area (m²) of the surfaces with highest changes in sediment connectivity due to the road network. That is:

• CA_RC95 = {CA | RC ≥ 3.12}

The landscape distribution of those surfaces, in terms of proximity to the hilltops and valleys, is described by the density plot of the raster file CA_RC95.tif in R:

library("raster")
library("ggplot2")

CA_RC95<-raster("CA_RC95.tif")
CA_RC95<-CA_RC95*0.0025

df = as.data.frame(CA_RC95)
df = na.omit(df)

ggplot(df,aes(CA_RC95)) +
 geom_histogram(aes(y=..count..*25),binwidth = 50)+
 geom_density(aes(y=50 * ..count..*25), col="blue",size=2, adjust=10000)+
 xlab("Contributing Area [ha] 
 Hilltop                  Valley") + ylab("Area [m2]")+
 theme(axis.text.x = element_text(face="bold", size=30),
    plot.title = element_text(color="black", size=40, face="bold",hjust=0.5),
    axis.title.x=element_text(color="blue", size=40, face="bold"),
    axis.text.y = element_text(face="bold", size=30),
    axis.title.y=element_text(color="blue", size=40, face="bold"))+ scale_y_continuous(trans = 'log10')+
 ggtitle("Upstream area of surfaces with 
 High Road Connectivity (RC > 3.12)")

Bibliography

1. OpenStreetMap contributors. Planet dump retrieved from https://planet.osm.org. https://www.openstreetmap.org/ (2017).

2. Cavalli, M., Trevisani, S., Comiti, F. & Marchi, L. Geomorphometric assessment of spatial sediment connectivity in small Alpine catchments. Geomorphology 188, 31–41 (2013).

3. Crema, S. & Cavalli, M. SedInConnect: a stand-alone, free and open source tool for the assessment of sediment connectivity. Computers and Geosciences 111, 39–45 (2018).

4. Tarboton, D. G. A new method for the determination of flow directions and upslope areas in grid digital elevation models. Water Resources Research 33, 309–319 (1997).

The “NSDI Zambia Operational School Points and Names, Version 01 (Beta)” provides school and school affiliated point locations, names, types, and source of the data. The dataset was developed by compiling and standardizing existing government data sources of school point locations and names data from the 2010 census cartography from Zambia Statistics Agency (ZamStats), the Ministry of General Education (MoGE) and the Ministry of Water Development Sanitation and Environmental Protection (MWDSEP).The dataset is available for download in shapefile format and can be viewed in Geographic Information Systems(GIS) such as ArcMap, QGIS, or Google Earth (Pro). The data is available for all of Zambia. It has the following attributes: Name, Original Name (from original dataset), Type, Sub Type, Source, Province (Code), District (Code), Ward (Code), Constituency (Code), Global IDFor more information about the settlement data and methodology, see the data release notes here.

Dataset for: Bedding scale correlation on Mars in western Arabia Terra

A.M. Annex et al.

Data Product Overview

This repository contains all source data for the publication. Below is a description of each general data product type, software that can load the data, and a list of the file names along with the short description of the data product.

HiRISE Digital Elevation Models (DEMs).

HiRISE DEMs produced using the Ames Stereo Pipeline are in geotiff format ending with ‘*X_0_DEM-adj.tif’, the “X” prefix denotes the spatial resolution of the data product in meters. Geotiff files are able to be read by free GIS software like QGIS.

HiRISE map-projected imagery (DRGs).

Map-projected HiRISE images produced using the Ames Stereo Pipeline are in geotiff format ending with ‘*0_Y_DRG-cog.tif’, the “Y” prefix denotes the spatial resolution of the data product in centimeters. Geotiff files are able to be read by free GIS software like QGIS. The DRG files are formatted as COG-geotiffs for enhanced compression and ease of use.

3D Topography files (.ply).

Traingular Mesh versions of the HiRISE/CTX topography data used for 3D figures in “.ply” format. Meshes are greatly geometrically simplified from source files. Topography files can be loaded in a variety of open source tools like ParaView and Meshlab. Textures can be applied using embedded texture coordinates.

3D Geological Model outputs (.vtk)

VTK 3D file format files of model output over the spatial domain of each study site. VTK files can be loaded by ParaView open source software. The “block” files contain the model evaluation over a regular grid over the model extent. The “surfaces” files contain just the bedding surfaces as interpolated from the “block” files using the marching cubes algorithm.

Geological Model geologic maps (geologic_map.tif).

Geologic maps from geological models are standard geotiffs readable by conventional GIS software. The maximum value for each geologic map is the “no-data” value for the map. Geologic maps are calculated at a lower resolution than the topography data for storage efficiency.

Beds Geopackage File (.gpkg).

Geopackage vector data file containing all mapped layers and associated metadata including dip corrected bed thickness as well as WKB encoded 3D linestrings representing the sampled topography data to which the bedding orientations were fit. Geopackage files can be read using GIS software like QGIS and ArcGIS as well as the OGR/GDAL suite. A full description of each column in the file is provided below.

    Column
    Type
    Description




    uuid
    String
    unique identifier


    stratum_order
    Real
    0-indexed bed order


    section
    Real
    section number


    layer_id
    Real
    bed number/index


    layer_id_bk
    Real
    unused backup bed number/index


    source_raster
    String
    dem file path used


    raster
    String
    dem file name


    gsd
    Real
    ground sampling distant for dem


    wkn
    String
    well known name for dem


    rtype
    String
    raster type


    minx
    Real
    minimum x position of trace in dem crs


    miny
    Real
    minimum y position of trace in dem crs


    maxx
    Real
    maximum x position of trace in dem crs


    maxy
    Real
    maximum y position of trace in dem crs


    method
    String
    internal interpolation method


    sl
    Real
    slope in degrees


    az
    Real
    azimuth in degrees


    error
    Real
    maximum error ellipse angle


    stdr
    Real
    standard deviation of the residuals


    semr
    Real
    standard error of the residuals


    X
    Real
    mean x position in CRS


    Y
    Real
    mean y position in CRS


    Z
    Real
    mean z position in CRS


    b1
    Real
    plane coefficient 1


    b2
    Real
    plane coefficient 2


    b3
    Real
    plane coefficient 3


    b1_se
    Real
    standard error plane coefficient 1


    b2_se
    Real
    standard error plane coefficient 2


    b3_se
    Real
    standard error plane coefficient 3


    b1_ci_low
    Real
    plane coefficient 1 95% confidence interval low


    b1_ci_high
    Real
    plane coefficient 1 95% confidence interval high


    b2_ci_low
    Real
    plane coefficient 2 95% confidence interval low


    b2_ci_high
    Real
    plane coefficient 2 95% confidence interval high


    b3_ci_low
    Real
    plane coefficient 3 95% confidence interval low


    b3_ci_high
    Real
    plane coefficient 3 95% confidence interval high


    pca_ev_1
    Real
    pca explained variance ratio pc 1


    pca_ev_2
    Real
    pca explained variance ratio pc 2


    pca_ev_3
    Real
    pca explained variance ratio pc 3


    condition_number
    Real
    condition number for regression


    n
    Integer64
    number of data points used in regression


    rls
    Integer(Boolean)
    unused flag


    demeaned_regressions
    Integer(Boolean)
    centering indicator


    meansl
    Real
    mean section slope


    meanaz
    Real
    mean section azimuth


    angular_error
    Real
    angular error for section


    mB_1
    Real
    mean plane coefficient 1 for section


    mB_2
    Real
    mean plane coefficient 2 for section


    mB_3
    Real
    mean plane coefficient 3 for section


    R
    Real
    mean plane normal orientation vector magnitude


    num_valid
    Integer64
    number of valid planes in section


    meanc
    Real
    mean stratigraphic position


    medianc
    Real
    median stratigraphic position


    stdc
    Real
    standard deviation of stratigraphic index


    stec
    Real
    standard error of stratigraphic index


    was_monotonic_increasing_layer_id
    Integer(Boolean)
    monotonic layer_id after projection to stratigraphic index


    was_monotonic_increasing_meanc
    Integer(Boolean)
    monotonic meanc after projection to stratigraphic index


    was_monotonic_increasing_z
    Integer(Boolean)
    monotonic z increasing after projection to stratigraphic index


    meanc_l3sigma_std
    Real
    lower 3-sigma meanc standard deviation


    meanc_u3sigma_std
    Real
    upper 3-sigma meanc standard deviation


    meanc_l2sigma_sem
    Real
    lower 3-sigma meanc standard error


    meanc_u2sigma_sem
    Real
    upper 3-sigma meanc standard error


    thickness
    Real
    difference in meanc


    thickness_fromz
    Real
    difference in Z value


    dip_cor
    Real
    dip correction


    dc_thick
    Real
    thickness after dip correction


    dc_thick_fromz
    Real
    z thickness after dip correction


    dc_thick_dev
    Integer(Boolean)
    dc_thick <= total mean dc_thick


    dc_thick_fromz_dev
    Integer(Boolean)
    dc_thick <= total mean dc_thick_fromz


    thickness_fromz_dev
    Integer(Boolean)
    dc_thick <= total mean thickness_fromz


    dc_thick_dev_bg
    Integer(Boolean)
    dc_thick <= section mean dc_thick


    dc_thick_fromz_dev_bg
    Integer(Boolean)
    dc_thick <= section mean dc_thick_fromz


    thickness_fromz_dev_bg
    Integer(Boolean)
    dc_thick <= section mean thickness_fromz


    slr
    Real
    slope in radians


    azr
    Real
    azimuth in radians


    meanslr
    Real
    mean slope in radians


    meanazr
    Real
    mean azimuth in radians


    angular_error_r
    Real
    angular error of section in radians


    pca_ev_1_ok
    Integer(Boolean)
    pca_ev_1 < 99.5%


    pca_ev_2_3_ratio
    Real
    pca_ev_2/pca_ev_3


    pca_ev_2_3_ratio_ok
    Integer(Boolean)
    pca_ev_2_3_ratio > 15


    xyz_wkb_hex
    String
    hex encoded wkb geometry for all points used in regression

Geological Model input files (.gpkg).

Four geopackage (.gpkg) files represent the input dataset for the geological models, one per study site as specified in the name of the file. The files contain most of the columns described above in the Beds geopackage file, with the following additional columns. The final seven columns (azimuth, dip, polarity, formation, X, Y, Z) constituting the actual parameters used by the geological model (GemPy).

    Column
    Type
    Description




    azimuth_mean
    String
    Mean section dip azimuth 


    azimuth_indi
    Real
    Individual bed azimuth


    azimuth
    Real
    Azimuth of trace used by the geological model


    dip
    Real
    Dip for the trace used by the geological mode


    polarity
    Real
    Polarity of the dip vector normal vector 


    formation
    String
    String representation of layer_id required for GemPy models


    X
    Real
    X position in the CRS of the sampled point on the trace


    Y
    Real
    Y position in the CRS of the sampled point on the trace


    Z
    Real
    Z position in the CRS of the sampled point on the trace

Stratigraphic Column Files (.gpkg).

Stratigraphic columns computed from the Geological Models come in three kinds of Geopackage vector files indicated by the postfixes _sc, rbsc, and rbssc. File names include the wkn site name.

sc (_sc.gpkg).

Geopackage vector data file containing measured bed thicknesses from Geological Model joined with corresponding Beds Geopackage file, subsetted partially. The columns largely overlap with the the list above for the Beds Geopackage but with the following additions

    Column
    Type
    Description




    X
    Real
    X position of thickness measurement


    Y
    Real
    Y position of thickness measurement


    Z
    Real
    Z position of thickness measurement


    formation
    String
    Model required string representation of bed index


    bed thickness (m)
    Real
    difference of bed elevations


    azimuths
    Real
    azimuth as measured from model in degrees


    dip_degrees
    Real
    dip as measured from model in