The UHDM dataset contains 5,000 real-world 4K resolution image pairs, and is used to evaluate the effectiveness of ultra-high-definition demoiréing methods.

Overview

3DHD CityScenes is the most comprehensive, large-scale high-definition (HD) map dataset to date, annotated in the three spatial dimensions of globally referenced, high-density LiDAR point clouds collected in urban domains. Our HD map covers 127 km of road sections of the inner city of Hamburg, Germany including 467 km of individual lanes. In total, our map comprises 266,762 individual items.

Our corresponding paper (published at ITSC 2022) is available here. Further, we have applied 3DHD CityScenes to map deviation detection here.

Moreover, we release code to facilitate the application of our dataset and the reproducibility of our research. Specifically, our 3DHD_DevKit comprises:

Python tools to read, generate, and visualize the dataset,

3DHDNet deep learning pipeline (training, inference, evaluation) for map deviation detection and 3D object detection.

The DevKit is available here:

https://github.com/volkswagen/3DHD_devkit.

The dataset and DevKit have been created by Christopher Plachetka as project lead during his PhD period at Volkswagen Group, Germany.

When using our dataset, you are welcome to cite:

@INPROCEEDINGS{9921866, author={Plachetka, Christopher and Sertolli, Benjamin and Fricke, Jenny and Klingner, Marvin and Fingscheidt, Tim}, booktitle={2022 IEEE 25th International Conference on Intelligent Transportation Systems (ITSC)}, title={3DHD CityScenes: High-Definition Maps in High-Density Point Clouds}, year={2022}, pages={627-634}}

Acknowledgements

We thank the following interns for their exceptional contributions to our work.

Benjamin Sertolli: Major contributions to our DevKit during his master thesis

Niels Maier: Measurement campaign for data collection and data preparation

The European large-scale project Hi-Drive (www.Hi-Drive.eu) supports the publication of 3DHD CityScenes and encourages the general publication of information and databases facilitating the development of automated driving technologies.

The Dataset

After downloading, the 3DHD_CityScenes folder provides five subdirectories, which are explained briefly in the following.

1. Dataset

This directory contains the training, validation, and test set definition (train.json, val.json, test.json) used in our publications. Respective files contain samples that define a geolocation and the orientation of the ego vehicle in global coordinates on the map.

During dataset generation (done by our DevKit), samples are used to take crops from the larger point cloud. Also, map elements in reach of a sample are collected. Both modalities can then be used, e.g., as input to a neural network such as our 3DHDNet.

To read any JSON-encoded data provided by 3DHD CityScenes in Python, you can use the following code snipped as an example.

import json

json_path = r"E:\3DHD_CityScenes\Dataset\train.json" with open(json_path) as jf: data = json.load(jf) print(data)

1. HD_Map

Map items are stored as lists of items in JSON format. In particular, we provide:

traffic signs,

traffic lights,

pole-like objects,

construction site locations,

construction site obstacles (point-like such as cones, and line-like such as fences),

line-shaped markings (solid, dashed, etc.),

polygon-shaped markings (arrows, stop lines, symbols, etc.),

lanes (ordinary and temporary),

relations between elements (only for construction sites, e.g., sign to lane association).

1. HD_Map_MetaData

Our high-density point cloud used as basis for annotating the HD map is split in 648 tiles. This directory contains the geolocation for each tile as polygon on the map. You can view the respective tile definition using QGIS. Alternatively, we also provide respective polygons as lists of UTM coordinates in JSON.

Files with the ending .dbf, .prj, .qpj, .shp, and .shx belong to the tile definition as “shape file” (commonly used in geodesy) that can be viewed using QGIS. The JSON file contains the same information provided in a different format used in our Python API.

1. HD_PointCloud_Tiles

The high-density point cloud tiles are provided in global UTM32N coordinates and are encoded in a proprietary binary format. The first 4 bytes (integer) encode the number of points contained in that file. Subsequently, all point cloud values are provided as arrays. First all x-values, then all y-values, and so on. Specifically, the arrays are encoded as follows.

x-coordinates: 4 byte integer

y-coordinates: 4 byte integer

z-coordinates: 4 byte integer

intensity of reflected beams: 2 byte unsigned integer

ground classification flag: 1 byte unsigned integer

After reading, respective values have to be unnormalized. As an example, you can use the following code snipped to read the point cloud data. For visualization, you can use the pptk package, for instance.

import numpy as np import pptk

file_path = r"E:\3DHD_CityScenes\HD_PointCloud_Tiles\HH_001.bin" pc_dict = {} key_list = ['x', 'y', 'z', 'intensity', 'is_ground'] type_list = ['

Objective: To develop a clinical informatics pipeline designed to capture large-scale structured EHR data for a national patient registry.

Materials and Methods: The EHR-R-REDCap pipeline is implemented using R-statistical software to remap and import structured EHR data into the REDCap-based multi-institutional Merkel Cell Carcinoma (MCC) Patient Registry using an adaptable data dictionary.

Results: Clinical laboratory data were extracted from EPIC Clarity across several participating institutions. Labs were transformed, remapped and imported into the MCC registry using the EHR labs abstraction (eLAB) pipeline. Forty-nine clinical tests encompassing 482,450 results were imported into the registry for 1,109 enrolled MCC patients. Data-quality assessment revealed highly accurate, valid labs. Univariate modeling was performed for labs at baseline on overall survival (N=176) using this clinical informatics pipeline.

Conclusion: We demonstrate feasibility of the facile eLAB workflow. EHR data is successfully transformed, and bulk-loaded/imported into a REDCap-based national registry to execute real-world data analysis and interoperability.

Methods eLAB Development and Source Code (R statistical software):

eLAB is written in R (version 4.0.3), and utilizes the following packages for processing: DescTools, REDCapR, reshape2, splitstackshape, readxl, survival, survminer, and tidyverse. Source code for eLAB can be downloaded directly (https://github.com/TheMillerLab/eLAB).

eLAB reformats EHR data abstracted for an identified population of patients (e.g. medical record numbers (MRN)/name list) under an Institutional Review Board (IRB)-approved protocol. The MCCPR does not host MRNs/names and eLAB converts these to MCCPR assigned record identification numbers (record_id) before import for de-identification.

Functions were written to remap EHR bulk lab data pulls/queries from several sources including Clarity/Crystal reports or institutional EDW including Research Patient Data Registry (RPDR) at MGB. The input, a csv/delimited file of labs for user-defined patients, may vary. Thus, users may need to adapt the initial data wrangling script based on the data input format. However, the downstream transformation, code-lab lookup tables, outcomes analysis, and LOINC remapping are standard for use with the provided REDCap Data Dictionary, DataDictionary_eLAB.csv. The available R-markdown ((https://github.com/TheMillerLab/eLAB) provides suggestions and instructions on where or when upfront script modifications may be necessary to accommodate input variability.

The eLAB pipeline takes several inputs. For example, the input for use with the ‘ehr_format(dt)’ single-line command is non-tabular data assigned as R object ‘dt’ with 4 columns: 1) Patient Name (MRN), 2) Collection Date, 3) Collection Time, and 4) Lab Results wherein several lab panels are in one data frame cell. A mock dataset in this ‘untidy-format’ is provided for demonstration purposes (https://github.com/TheMillerLab/eLAB).

Bulk lab data pulls often result in subtypes of the same lab. For example, potassium labs are reported as “Potassium,” “Potassium-External,” “Potassium(POC),” “Potassium,whole-bld,” “Potassium-Level-External,” “Potassium,venous,” and “Potassium-whole-bld/plasma.” eLAB utilizes a key-value lookup table with ~300 lab subtypes for remapping labs to the Data Dictionary (DD) code. eLAB reformats/accepts only those lab units pre-defined by the registry DD. The lab lookup table is provided for direct use or may be re-configured/updated to meet end-user specifications. eLAB is designed to remap, transform, and filter/adjust value units of semi-structured/structured bulk laboratory values data pulls from the EHR to align with the pre-defined code of the DD.

Data Dictionary (DD)

EHR clinical laboratory data is captured in REDCap using the ‘Labs’ repeating instrument (Supplemental Figures 1-2). The DD is provided for use by researchers at REDCap-participating institutions and is optimized to accommodate the same lab-type captured more than once on the same day for the same patient. The instrument captures 35 clinical lab types. The DD serves several major purposes in the eLAB pipeline. First, it defines every lab type of interest and associated lab unit of interest with a set field/variable name. It also restricts/defines the type of data allowed for entry for each data field, such as a string or numerics. The DD is uploaded into REDCap by every participating site/collaborator and ensures each site collects and codes the data the same way. Automation pipelines, such as eLAB, are designed to remap/clean and reformat data/units utilizing key-value look-up tables that filter and select only the labs/units of interest. eLAB ensures the data pulled from the EHR contains the correct unit and format pre-configured by the DD. The use of the same DD at every participating site ensures that the data field code, format, and relationships in the database are uniform across each site to allow for the simple aggregation of the multi-site data. For example, since every site in the MCCPR uses the same DD, aggregation is efficient and different site csv files are simply combined.

Study Cohort

This study was approved by the MGB IRB. Search of the EHR was performed to identify patients diagnosed with MCC between 1975-2021 (N=1,109) for inclusion in the MCCPR. Subjects diagnosed with primary cutaneous MCC between 2016-2019 (N= 176) were included in the test cohort for exploratory studies of lab result associations with overall survival (OS) using eLAB.

Statistical Analysis

OS is defined as the time from date of MCC diagnosis to date of death. Data was censored at the date of the last follow-up visit if no death event occurred. Univariable Cox proportional hazard modeling was performed among all lab predictors. Due to the hypothesis-generating nature of the work, p-values were exploratory and Bonferroni corrections were not applied.

This dataset comes from the Community Survey questions relating to the Community Health & Well-Being performance measure: "With “10” representing the best possible life for you and “0” representing the worst, how would you say you personally feel you stand at this time?" and "With “10” representing the best possible life for you and “0” representing the worst, how do you think you will stand about five years from now?" – the results of both scores are then used to assess a Cantril Scale which is a way of assessing general life satisfaction. As per the Cantril Self-Anchoring Striving Scale, the three categories of identification are as follows: Thriving – Respondents rate their current life as a 7 or higher AND their future life as an 8 or higher. Suffering – Respondents rate their current life negatively (0 to 4) AND their future life negatively (0 to 4). Struggling – Respondents who do not meet the criteria for Thriving or Suffering. The survey is mailed to a random sample of households in the City of Tempe and has a 95% confidence level. Note on Methodology Update: In 2025, the Cantril classification method was revised to align with Gallup’s official Life Evaluation Index methodology. This change affects only a small number of respondents whose answers did not fit cleanly into the previous custom definition of “Struggling,” which classified respondents who rated their current life moderately (5 or 6) or their future life moderately or negatively (0 to 7). Under the updated approach, respondents who previously fell outside that definition are now appropriately included in the Struggling category. The overall distribution of Thriving, Struggling, and Suffering changed only minimally, and the updated methodology has been applied consistently to all prior years.This page provides data for the Community Health and Well-Being performance measure.The performance measure dashboard is available at 3.34 Community Health and Well-Being.Data Dictionary Additional InformationSource: Community Attitude Survey (Vendor: ETC Institute)Contact: Amber AsburryContact email: amber_asburry@tempe.govPreparation Method: Survey results from two questions are calculated to create a Cantril Scale value that falls into the categories of Thriving, Struggling, and Suffering.Publish Frequency: AnnuallyPublish Method: Manual

Overview The Office of the Geographer and Global Issues at the U.S. Department of State produces the Large Scale International Boundaries (LSIB) dataset. The current edition is version 11.4 (published 24 February 2025). The 11.4 release contains updated boundary lines and data refinements designed to extend the functionality of the dataset. These data and generalized derivatives are the only international boundary lines approved for U.S. Government use. The contents of this dataset reflect U.S. Government policy on international boundary alignment, political recognition, and dispute status. They do not necessarily reflect de facto limits of control. National Geospatial Data Asset This dataset is a National Geospatial Data Asset (NGDAID 194) managed by the Department of State. It is a part of the International Boundaries Theme created by the Federal Geographic Data Committee. Dataset Source Details Sources for these data include treaties, relevant maps, and data from boundary commissions, as well as national mapping agencies. Where available and applicable, the dataset incorporates information from courts, tribunals, and international arbitrations. The research and recovery process includes analysis of satellite imagery and elevation data. Due to the limitations of source materials and processing techniques, most lines are within 100 meters of their true position on the ground. Cartographic Visualization The LSIB is a geospatial dataset that, when used for cartographic purposes, requires additional styling. The LSIB download package contains example style files for commonly used software applications. The attribute table also contains embedded information to guide the cartographic representation. Additional discussion of these considerations can be found in the Use of Core Attributes in Cartographic Visualization section below. Additional cartographic information pertaining to the depiction and description of international boundaries or areas of special sovereignty can be found in Guidance Bulletins published by the Office of the Geographer and Global Issues: https://data.geodata.state.gov/guidance/index.html Contact Direct inquiries to internationalboundaries@state.gov. Direct download: https://data.geodata.state.gov/LSIB.zip Attribute Structure The dataset uses the following attributes divided into two categories: ATTRIBUTE NAME | ATTRIBUTE STATUS CC1 | Core CC1_GENC3 | Extension CC1_WPID | Extension COUNTRY1 | Core CC2 | Core CC2_GENC3 | Extension CC2_WPID | Extension COUNTRY2 | Core RANK | Core LABEL | Core STATUS | Core NOTES | Core LSIB_ID | Extension ANTECIDS | Extension PREVIDS | Extension PARENTID | Extension PARENTSEG | Extension These attributes have external data sources that update separately from the LSIB: ATTRIBUTE NAME | ATTRIBUTE STATUS CC1 | GENC CC1_GENC3 | GENC CC1_WPID | World Polygons COUNTRY1 | DoS Lists CC2 | GENC CC2_GENC3 | GENC CC2_WPID | World Polygons COUNTRY2 | DoS Lists LSIB_ID | BASE ANTECIDS | BASE PREVIDS | BASE PARENTID | BASE PARENTSEG | BASE The core attributes listed above describe the boundary lines contained within the LSIB dataset. Removal of core attributes from the dataset will change the meaning of the lines. An attribute status of “Extension” represents a field containing data interoperability information. Other attributes not listed above include “FID”, “Shape_length” and “Shape.” These are components of the shapefile format and do not form an intrinsic part of the LSIB. Core Attributes The eight core attributes listed above contain unique information which, when combined with the line geometry, comprise the LSIB dataset. These Core Attributes are further divided into Country Code and Name Fields and Descriptive Fields. County Code and Country Name Fields “CC1” and “CC2” fields are machine readable fields that contain political entity codes. These are two-character codes derived from the Geopolitical Entities, Names, and Codes Standard (GENC), Edition 3 Update 18. “CC1_GENC3” and “CC2_GENC3” fields contain the corresponding three-character GENC codes and are extension attributes discussed below. The codes “Q2” or “QX2” denote a line in the LSIB representing a boundary associated with areas not contained within the GENC standard. The “COUNTRY1” and “COUNTRY2” fields contain the names of corresponding political entities. These fields contain names approved by the U.S. Board on Geographic Names (BGN) as incorporated in the ‘"Independent States in the World" and "Dependencies and Areas of Special Sovereignty" lists maintained by the Department of State. To ensure maximum compatibility, names are presented without diacritics and certain names are rendered using common cartographic abbreviations. Names for lines associated with the code "Q2" are descriptive and not necessarily BGN-approved. Names rendered in all CAPITAL LETTERS denote independent states. Names rendered in normal text represent dependencies, areas of special sovereignty, or are otherwise presented for the convenience of the user. Descriptive Fields The following text fields are a part of the core attributes of the LSIB dataset and do not update from external sources. They provide additional information about each of the lines and are as follows: ATTRIBUTE NAME | CONTAINS NULLS RANK | No STATUS | No LABEL | Yes NOTES | Yes Neither the "RANK" nor "STATUS" fields contain null values; the "LABEL" and "NOTES" fields do. The "RANK" field is a numeric expression of the "STATUS" field. Combined with the line geometry, these fields encode the views of the United States Government on the political status of the boundary line. ATTRIBUTE NAME | | VALUE | RANK | 1 | 2 | 3 STATUS | International Boundary | Other Line of International Separation | Special Line A value of “1” in the “RANK” field corresponds to an "International Boundary" value in the “STATUS” field. Values of ”2” and “3” correspond to “Other Line of International Separation” and “Special Line,” respectively. The “LABEL” field contains required text to describe the line segment on all finished cartographic products, including but not limited to print and interactive maps. The “NOTES” field contains an explanation of special circumstances modifying the lines. This information can pertain to the origins of the boundary lines, limitations regarding the purpose of the lines, or the original source of the line. Use of Core Attributes in Cartographic Visualization Several of the Core Attributes provide information required for the proper cartographic representation of the LSIB dataset. The cartographic usage of the LSIB requires a visual differentiation between the three categories of boundary lines. Specifically, this differentiation must be between: International Boundaries (Rank 1); Other Lines of International Separation (Rank 2); and Special Lines (Rank 3). Rank 1 lines must be the most visually prominent. Rank 2 lines must be less visually prominent than Rank 1 lines. Rank 3 lines must be shown in a manner visually subordinate to Ranks 1 and 2. Where scale permits, Rank 2 and 3 lines must be labeled in accordance with the “Label” field. Data marked with a Rank 2 or 3 designation does not necessarily correspond to a disputed boundary. Please consult the style files in the download package for examples of this depiction. The requirement to incorporate the contents of the "LABEL" field on cartographic products is scale dependent. If a label is legible at the scale of a given static product, a proper use of this dataset would encourage the application of that label. Using the contents of the "COUNTRY1" and "COUNTRY2" fields in the generation of a line segment label is not required. The "STATUS" field contains the preferred description for the three LSIB line types when they are incorporated into a map legend but is otherwise not to be used for labeling. Use of the “CC1,” “CC1_GENC3,” “CC2,” “CC2_GENC3,” “RANK,” or “NOTES” fields for cartographic labeling purposes is prohibited. Extension Attributes Certain elements of the attributes within the LSIB dataset extend data functionality to make the data more interoperable or to provide clearer linkages to other datasets. The fields “CC1_GENC3” and “CC2_GENC” contain the corresponding three-character GENC code to the “CC1” and “CC2” attributes. The code “QX2” is the three-character counterpart of the code “Q2,” which denotes a line in the LSIB representing a boundary associated with a geographic area not contained within the GENC standard. To allow for linkage between individual lines in the LSIB and World Polygons dataset, the “CC1_WPID” and “CC2_WPID” fields contain a Universally Unique Identifier (UUID), version 4, which provides a stable description of each geographic entity in a boundary pair relationship. Each UUID corresponds to a geographic entity listed in the World Polygons dataset. These fields allow for linkage between individual lines in the LSIB and the overall World Polygons dataset. Five additional fields in the LSIB expand on the UUID concept and either describe features that have changed across space and time or indicate relationships between previous versions of the feature. The “LSIB_ID” attribute is a UUID value that defines a specific instance of a feature. Any change to the feature in a lineset requires a new “LSIB_ID.” The “ANTECIDS,” or antecedent ID, is a UUID that references line geometries from which a given line is descended in time. It is used when there is a feature that is entirely new, not when there is a new version of a previous feature. This is generally used to reference countries that have dissolved. The “PREVIDS,” or Previous ID, is a UUID field that contains old versions of a line. This is an additive field, that houses all Previous IDs. A new version of a feature is defined by any change to the

The monthly means of ECMWF ERA-40 reanalysis isentropic level analysis data are in this dataset.

This dataset contains ERA5 surface level analysis parameter data ensemble means (see linked dataset for spreads). ERA5 is the 5th generation reanalysis project from the European Centre for Medium-Range Weather Forecasts (ECWMF) - see linked documentation for further details. The ensemble means and spreads are calculated from the ERA5 10 member ensemble, run at a reduced resolution compared with the single high resolution (hourly output at 31 km grid spacing) 'HRES' realisation, for which these data have been produced to provide an uncertainty estimate. This dataset contains a limited selection of all available variables and have been converted to netCDF from the original GRIB files held on the ECMWF system. They have also been translated onto a regular latitude-longitude grid during the extraction process from the ECMWF holdings. For a fuller set of variables please see the linked Copernicus Data Store (CDS) data tool, linked to from this record.

Note, ensemble standard deviation is often referred to as ensemble spread and is calculated as the standard deviation of the 10-members in the ensemble (i.e., including the control). It is not the sample standard deviation, and thus were calculated by dividing by 10 rather than 9 (N-1). See linked datasets for ensemble member and ensemble mean data.

The ERA5 global atmospheric reanalysis of the covers 1979 to 2 months behind the present month. This follows on from the ERA-15, ERA-40 rand ERA-interim re-analysis projects.

An initial release of ERA5 data (ERA5t) is made roughly 5 days behind the present date. These will be subsequently reviewed ahead of being released by ECMWF as quality assured data within 3 months. CEDA holds a 6 month rolling copy of the latest ERA5t data. See related datasets linked to from this record. However, for the period 2000-2006 the initial ERA5 release was found to suffer from stratospheric temperature biases and so new runs to address this issue were performed resulting in the ERA5.1 release (see linked datasets). Note, though, that Simmons et al. 2020 (technical memo 859) report that "ERA5.1 is very close to ERA5 in the lower and middle troposphere." but users of data from this period should read the technical memo 859 for further details.

Description and PurposeThese data include the individual responses for the City of Tempe Annual Community Survey conducted by ETC Institute. These data help determine priorities for the community as part of the City's on-going strategic planning process. Averaged Community Survey results are used as indicators for several city performance measures. The summary data for each performance measure is provided as an open dataset for that measure (separate from this dataset). The performance measures with indicators from the survey include the following (as of 2022):1. Safe and Secure Communities1.04 Fire Services Satisfaction1.06 Crime Reporting1.07 Police Services Satisfaction1.09 Victim of Crime1.10 Worry About Being a Victim1.11 Feeling Safe in City Facilities1.23 Feeling of Safety in Parks2. Strong Community Connections2.02 Customer Service Satisfaction2.04 City Website Satisfaction2.05 Online Services Satisfaction Rate2.15 Feeling Invited to Participate in City Decisions2.21 Satisfaction with Availability of City Information3. Quality of Life3.16 City Recreation, Arts, and Cultural Centers3.17 Community Services Programs3.19 Value of Special Events3.23 Right of Way Landscape Maintenance3.36 Quality of City Services4. Sustainable Growth & DevelopmentNo Performance Measures in this category presently relate directly to the Community Survey5. Financial Stability & VitalityNo Performance Measures in this category presently relate directly to the Community SurveyMethodsThe survey is mailed to a random sample of households in the City of Tempe. Follow up emails and texts are also sent to encourage participation. A link to the survey is provided with each communication. To prevent people who do not live in Tempe or who were not selected as part of the random sample from completing the survey, everyone who completed the survey was required to provide their address. These addresses were then matched to those used for the random representative sample. If the respondent’s address did not match, the response was not used. To better understand how services are being delivered across the city, individual results were mapped to determine overall distribution across the city. Additionally, demographic data were used to monitor the distribution of responses to ensure the responding population of each survey is representative of city population. Processing and LimitationsThe location data in this dataset is generalized to the block level to protect privacy. This means that only the first two digits of an address are used to map the location. When they data are shared with the city only the latitude/longitude of the block level address points are provided. This results in points that overlap. In order to better visualize the data, overlapping points were randomly dispersed to remove overlap. The result of these two adjustments ensure that they are not related to a specific address, but are still close enough to allow insights about service delivery in different areas of the city. This data is the weighted data provided by the ETC Institute, which is used in the final published PDF report.The 2022 Annual Community Survey report is available on data.tempe.gov. The individual survey questions as well as the definition of the response scale (for example, 1 means “very dissatisfied” and 5 means “very satisfied”) are provided in the data dictionary.Additional InformationSource: Community Attitude SurveyContact (author): Wydale HolmesContact E-Mail (author): wydale_holmes@tempe.govContact (maintainer): Wydale HolmesContact E-Mail (maintainer): wydale_holmes@tempe.govData Source Type: Excel tablePreparation Method: Data received from vendor after report is completedPublish Frequency: AnnualPublish Method: ManualData Dictionary

Executive Statement To support analysis of the Landsat long-term data record that began in 1972, the USGS Landsat data archive was reorganized into a formal tiered data collection structure. This structure ensures all Landsat Level 1 products provide a consistent archive of known data quality to support time-series analysis and data “stacking”, while controlling continuous improvement of the archive, and access to all data as they are acquired. Collection 1 Level 1 processing began in August 2016 and continued until all archived data was processed, completing May 2018. Newly-acquired Landsat 8 and Landsat 7 data continue to be processed into Collection 1 shortly after data is downlinked to USGS EROS.Learn more: https://www.usgs.gov/media/files/landsat-collection-1-level-1-product-definition

The SWOT Level 2 River Single-Pass Vector Data Product (SWOT_L2_HR_RiverSP_D) provides hydrologic measurements for predefined river reaches and nodes, derived from high-resolution radar observations collected by the Ka-band Radar Interferometer (KaRIn) aboard the SWOT satellite. This product reports water surface elevation, slope, width, area, and discharge estimates for each reach, along with corresponding node-level details. All features are defined by the Prior River Database (PRD), which encodes river geometry and topology across global basins.

Each granule covers a single satellite pass over one or more continents and includes two ESRI shapefiles: one for river reaches (as polylines) and one for nodes (as points). Shapefile attributes include both SWOT-derived measurements and metadata from the PRD. Water surface elevations are referenced to the WGS84 ellipsoid and are corrected for geoid height and solid Earth, load, and pole tides. Measurements are aggregated from lower-level pixel detections (PIXC product) assigned to hydrologic features via the auxiliary PIXCVec product. The product also includes consensus and algorithm-specific river discharge estimates, both unconstrained and constrained by historical gauge data.

The RiverSP product provides reach-scale hydrologic variables suitable for analyzing inland water dynamics, estimating discharge, and monitoring river changes over time. It enables direct integration with the PRD-defined river network and supports applications in large-scale hydrologic modeling, basin monitoring, and water resource management. Data are distributed in shapefile format with metadata and attribute definitions aligned to GIS and hydrologic standards.
This dataset is the parent collection to the following sub-collections:
https://podaac.jpl.nasa.gov/dataset/SWOT_L2_HR_RiverSP_node_D
https://podaac.jpl.nasa.gov/dataset/SWOT_L2_HR_RiverSP_reach_D

The Auto-generated 1:25000 Topographic Map Series is a series of hardcopy topographic maps covering eastern NSW that have been created using computerised scripting and fundamental spatial data held …Show full descriptionThe Auto-generated 1:25000 Topographic Map Series is a series of hardcopy topographic maps covering eastern NSW that have been created using computerised scripting and fundamental spatial data held by Land and Property Information (LPI) . These maps are created at a scale of 1:25000, where 1 cm on the map represents 250 m. The data is extracted from Land and Property Information (LPI)’s Digital Topographic Database (DTDB). The maps represent the State’s topographic features, including natural, physical and cultural aspects. All maps are accompanied by either an orthophoto captured through LPI’s aerial photography program or a satellite image sourced from SPOT 5 sensors. For more information on the DTDB and definitions of each feature class, feature instance and their attributes please refer to the LPI DTDB Data Dictionary and DTDB metadata. For more information on the accompanying orthophoto, please refer to its individual metadata record.

Abstract Surface Geology of Australia - Faults contains all brittle to ductile style structures, represented as lines, along which displacement has occurred, from a simple, single 'planar' brittle or ductile surface to a fault system comprised of many strands of both brittle and ductile nature. The 1:2.5M scale geology of Australia data documents the distribution and age of major stratigraphic, intrusive and medium to high-grade metamorphic rock units of onshore Australia. This edition contains the same geological content as previous editions (1998 to 2010), but is structured according to Geoscience Australia's 2012 data standards. The dataset was compiled to use at scales between 1:2,500,000 and 1:5,000,000 inclusive. The units distinguished/mapped mainly represent stratigraphic supergroups, regional intrusive associations and regional metamorphic complexes. Groupings of Precambrian units in the time-space diagram are generally separated by major time breaks; Phanerozoic units are grouped according to stratigraphic age i.e. System/Period. The time-space diagram has the added benefit that it provides a summary of units currently included on the themes. The method used to distinguish sedimentary and many volcanic units varies for each geological eon as follows:

Cenozoic units are morphological units which emphasise the relationship of the sedimentary fill to the landscape; Mesozoic units are regionally extensive to continent-wide time-rock units which emphasise the System of Period(s); Paleozoic units are stratotectonic units that emphasise either the dominant System or Period(s) or the range of Periods; Proterozoic units are commonly regional stratotectonic units - separated by major time breaks and split into the Paleoproterozoic, Mesoproterozoic and Neoproterozoic Eras - which are generally unique to each cratonic region; and Archean units are regional lithological units grouped into broad time divisions.

Metamorphic units are lithological units which emphasise the metamorphic facies and timing of the last major metamorphic event. Igneous units are regional units which emphasise the dominant lithology and are grouped into broad time divisions. Currency Date modified: December 2014 Modification frequency: As needed Data extent Spatial extent North: -8.8819° South: -47.1937° East: 163.1921° West: 109.2335° Source information Geoscience Australia catalog entry: Surface Geology of Australia 1:2.5 million scale dataset 2012 edition Lineage statement The geological content of the 2012 edition of the 1:2.5M surface geology of Australia is the same as the previous 2010 edition (ANZLIC dataset ID = ANZCW0703013817), restructured to comply with 2012 Geoscience Australia and international data standards. The original data was compiled from digital data, mainly at 1:2 500 000 scale, supplied by AGSO, GSWA, NTGS, PIRSA, GSQ, GSTAS, GSNSW and GSVIC and from data obtained from many other groups. In order to synthesise data from a variety of sources into a coherent product, the degree and nature of modification of the source data varied from case to case. Cenozoic and Mesozoic units were derived from sources, including the Cenozoic Paleogeographic Atlas of Australia (Landford et al., 1995), the Geology of Australia 1986 and a compilation of Cenozoic basins in the Alice Springs region by B.R. Senior et al. (AGSO Record 1994/66). The Phanerozoic units of southeastern Australia are substantially a modification of the 1:2 500 000 scale map entitled "Stratotectonic and Structural Elements of the Tasman Fold Belt System". The geology of Tasmania is a generalisation of data assembled as part of the TASGO project (a GSTAS and AGSO/AGCRC venture completed in 1997). The geology of South Australia is a highly generalised modification of the 1993 1:2 000 000 scale Geological Map of South Australia. For the Precambrian compilation, much of the geology of Western Australia has been derived from the Geological Map of Western Australia, 1988 with some modifications. The geology of the Kimberley, Halls Creek, Tanami and Arunta regions has been updated in line with recent mapping and some input from magnetic interpretation to emphasise relationships with the Tanami region. The geology of the Amadeus region has been generalised from the 1:1 000 000 scale "Structural Map of the Amadeus Basin" (Compiler A.J. Stewart). The geology of the Musgrave region has been re-compiled and simplified. The geology of North Queensland has been generalised by D. Palfreyman and D. Pillinger from the "North Qld Geology, 1997" 1:1 000 000 scale map (compilers J.H.C. Bain & D. Haipola). Data dictionary

Attribute name Description

faultType URI referring to a controlled vocabulary term defining the fault/shear type

faultType_uri URI link to a controlled vocabulary term for fault/shear type

name Display name for the fault or shear

description Text description of the fault or shear

exposure Indication of whether the mapped contact is exposed at the Earth surface. (ie, exposed, concealed)

faultFill Secondary or deformed material which may fill the structure. Term from a controlled vocabulary of earth material types

deformationStyle Describes the style of deformation (eg brittle, ductile etc) for the fault/shear

deformationStyle_uri URI referring to a controlled concept from a vocabulary defining the fault/shear deformation style

movementType Summarises the type of movement (eg dip-slip, strike-slip) on the fault/shear

movementType_uri URI referring to a controlled concept from a vocabulary defining the fault/shear movement type

movementSense Term describing the sense of movement (eg, dextral, sinistral) on the fault/shear

displacement Summarises the displacement across the fault/shear

dip Dip of the fault surface. Range = 0-90

dipDirection Dip direction of the fault surface. Range = 0-360

width True width (in metres) of the structure. Must be a number > 0, or null.

geologicHistory Text summary of the geologic history of the fault/shear. May include geologic age periods and deformation phase notation (ei, D1, D2, D3)

representativeAge_uri URI link to a controlled vocabulary term for the representative summary age for the fault or shear

representativeYoungerAge_uri URI link to a controlled vocabulary term for the older named age for the fault/shear

representativeOlderAge_uri URI link to a controlled vocabulary term for the younger named age for the fault/shear

faultSystemName The name of a larger fault system to which this structure may belong

faultSystemID Unique ID of a larger fault system to which this structure may belong

observationMethod Description of the observation method or compilation method used compile the mapped geologic structure

identityConfidence Description of the confidence in the interpretation of the geologic structure

positionalAccuracy_m Estimate of the accuracy of the mapped feature, in metres

source Text describing feature-specific details and citations to source materials, and if available providing URLs to reference material and publications describing the geologic feature. This could be a short text synopsis of key information that would also be in the metadata record referenced by metadata_uri.

metadata_uri URI referring to a metadata record describing the provenance of data

mappingFrame Description of the frame of reference of the mapped data (eg, earth surface, top of bedrock, top of Neoproterozoic basement)

resolutionScale The denominator of the scale at which the mapped data is designed to be represented

captureScale The denominator of the scale of data from which the mapped feature has been compiled

captureDate The date of original data capture for this mapped feature

modifiedDate The date of modification of this mapped feature, if applicable

plotRank A numeric indicator of the intention for how this mapped feature is to be plotted on a map. (1 = normal plotting feature; 2 = non-plotting feature

symbol Identifier for a symbol from symbolization scheme for portrayal

mappedFeatureID Unique identifier (URI) for the mapped line segment

faultID Unique identifier (URI) linking to a GeoSciML geologic feature instance which describes this mapped feature. Maps to 'SpecificationID' in GeoSciML-Portrayal

Contact Geoscience Australia, clientservices@ga.gov.au

The Soil Geographical Data Base of France at Scale 1:1,000,000 is part of the European Soil Geographical Data Base of Europe. It is the resulting product of a collaborative project involving all the European Union and neighbouring countries. It is a simplified representation of the diversity and spatial variability of the soil coverage for France. The methodology used to differentiate and name the main soil types is based on the terminology of the F.A.O. legend for the Soil Map of the World at Scale 1:5,000,000. This terminology has been refined and adapted to take account of the specificities of the landscapes in Europe. It is itself founded on the distinction of the main pedogenetic processes leading to soil differentiation. The database contains a list of Soil Typological Units (STU). Besides the soil names they represent, these units are described by variables (attributes) specifying the nature and properties of the soils: for example the texture, the water regime, etc. The geographical representation was chosen at a scale corresponding to the 1:1,000,000. At this scale, it is not feasible to delineate the STUs. Therefore they are grouped into Soil Mapping Units (SMU) to form soil associations and to illustrate the functioning of pedological systems within the landscapes. Harmonisation of the soil data from the member countries is based on a dictionary giving the definition for each occurrence of the variables. Considering the scale, the precision of the variables is weak. Furthermore these variables were estimated over large areas by expert judgement rather than measured on local soil samples. This expertise results from synthesis and generalisation tasks of national or regional maps published at more detailed scales, for example 1:50,000 or 1:25,000 scales. Delineation of the Soil Mapping Units is also the result of expertise and experience. The spatial variability of soils is very important and is difficult to express at global levels of precision. Quality indices of the information (purity and confidence level) are included with the data in order to guide usage.

Interstates are a definition query from RoadInvReadOnly. Map Service & Feature Service is a line feature class from the Transportation feature dataset. Intended for use in any desktop maps or visual display in Portal web maps and web applications. Scale range displaying max out beyond map scale of 1:2,000,000 and the label class scale range max out to 24,000. Definition Query by ST_CODE field used to publish the service. No the Time zone property set.

Part of a set of two collections for patient-level costing, which provide a consistent approach to reporting cost information at patient level.

The Auto-generated 1:25000 Topographic Map Series is a series of hardcopy topographic maps covering eastern NSW that have been created using computerised scripting and fundamental spatial data held …Show full descriptionThe Auto-generated 1:25000 Topographic Map Series is a series of hardcopy topographic maps covering eastern NSW that have been created using computerised scripting and fundamental spatial data held by Land and Property Information (LPI) . These maps are created at a scale of 1:25000, where 1 cm on the map represents 250 m. The data is extracted from Land and Property Information (LPI)’s Digital Topographic Database (DTDB). The maps represent the State’s topographic features, including natural, physical and cultural aspects. All maps are accompanied by either an orthophoto captured through LPI’s aerial photography program or a satellite image sourced from SPOT 5 sensors. For more information on the DTDB and definitions of each feature class, feature instance and their attributes please refer to the LPI DTDB Data Dictionary and DTDB metadata. For more information on the accompanying orthophoto, please refer to its individual metadata record.

The First, Second, and Third Edition Topographic Map Series are series of hardcopy topographic maps covering NSW. The maps were produced by the Land and Property Information, a Division of the …Show full descriptionThe First, Second, and Third Edition Topographic Map Series are series of hardcopy topographic maps covering NSW. The maps were produced by the Land and Property Information, a Division of the Department of Finance and Services or equivalent department between 1970 and 2011. The maps represent the State’s topographic features, including natural, physical and cultural aspects at a scale of 1:25000, where 1 cm on the map represents 250 m. These maps have been progressively replaced with the autogenerated series since 2011. For more information on the Digital Topographic Database (DTDB) and definitions of each feature class, feature instance and their attributes please refer to the Land and Property DTDB Data Dictionary and DTDB metadata. For more information on the accompanying ADS orthophoto or the autogenerated map series, please refer to their individual metadata records.

The Auto-generated 1:25000 Topographic Map Series is a series of hardcopy topographic maps covering eastern NSW that have been created using computerised scripting and fundamental spatial data held …Show full descriptionThe Auto-generated 1:25000 Topographic Map Series is a series of hardcopy topographic maps covering eastern NSW that have been created using computerised scripting and fundamental spatial data held by Land and Property Information (LPI) . These maps are created at a scale of 1:25000, where 1 cm on the map represents 250 m. The data is extracted from Land and Property Information (LPI)’s Digital Topographic Database (DTDB). The maps represent the State’s topographic features, including natural, physical and cultural aspects. All maps are accompanied by either an orthophoto captured through LPI’s aerial photography program or a satellite image sourced from SPOT 5 sensors. For more information on the DTDB and definitions of each feature class, feature instance and their attributes please refer to the LPI DTDB Data Dictionary and DTDB metadata. For more information on the accompanying orthophoto, please refer to its individual metadata record.

General description Within URBANWASTE Work Package 2 data from the pilot cases needed to perform the metabolic analysis was collected. In this sense, mainly data regarding waste generation and management, tourism (accommodation capacity, tourist flows, tourism economy) and socio-economic data of each pilot was collected. The indicator sets finally collected were previously cross-checked with the 11 URBANWASTE Pilot Cases regarding data availability on pilot case scale to ensure their suitability and practicability to answer specific URBANWASTE questions. This cross-checking was done by the means of performing a "Survey on data availability" within Task 2.3. Origin, Nature and scale of data For data collection, all pilot cases partners received an empty excel database divided into three thematic areas (waste related data, socio-economic data and tourism related data). In case the pilot case partners did not have access to the requested information, other organisations such as local municipal departments, waste management companies, tourism associations, national statistical agencies etc. were contacted by them for support in data provision. The data collected with these databases mainly represent statistical data. For transparency reasons, data sources were to be specified as well. The spatial scale of the collected data was supposed to be the pilot case area (meaning for the whole city, municipality or metropolitan area). As data on this small scale was not available for all data sets, some of the provided data is on regional or even national level. For ensuring transparency, the spatial scale had to be specified for each data set. According to the type of indicators, the temporal scale varies from annual data to monthly data. For selected data sets, time series data at annual scale were collected for the period 2000 – 2015. For some selected data sets (e.g. waste quantities, tourist arrivals & overnight stays), additionally, also time series on monthly scale were collected for the period 2013 – 2015. Data Format The database prepared to collect the data needed for performing the metabolic analysis was divided into three thematic areas, which are further divided in categories as indicated below: Waste related data - Waste generation and waste quantities [number] - Waste prevention [text] [number] - Waste management [number] [%] [€] Socio-economic data - Description of the pilot case [number] [km²] - Economy [number] [%] [€] - Society [number] [%] - Building statistics [%] Tourism related data - Tourism economy [€] - Accommodation capacity [number] - Tourist flows [number] - Other tourism related information [number] Each category contains a lot of indicators, each indicator being identified by a data ID, a unit, and a spatial scale. Data sources had to be specified as well. When needed, the definitions of these indicators were added directly in the database template. In total, 48 data sets (some of them further divided into sub-sets) were collected. Most of the collected data represent quantitative data in the format of [number], [%] [€] or [km²]. The data on urban metabolism received from the pilot cases is stored in 1 excel database. Further Information and Contact The data on waste generation and management, socio-economic data and tourism data used for all the assessments performed within Work Package 2 and presented in this report was provided by the URBANWASTE pilot cases. More detailed information is contained within the database. In case of questions related to this database please contact: abf@boku.ac.at For more information on the URBANWASTE project please visit: http://www.urban-waste.eu/

User Knowledge Modeling Data Set

Predict student's knowledge level

• Level: Beginner
• Recommended Use: Classification/Clustering
• Domain: Education/Web

https://img.freepik.com/free-photo/group-happy-young-students-university_85574-4531.jpg" alt="student">

This beginner level data set has 403 rows and 6 columns. It is a real dataset about the students' knowledge status about the subject of Electrical DC Machines. This data set is recommended for learning and practicing your skills in exploratory data analysis, data visualization, and classification and clustering techniques. Feel free to explore the data set with multiple supervised and unsupervised learning techniques. The Following data dictionary gives more details on this data set:

|Column Position|Atribute Name|Definition|Data Type|Example| | --- | --- | |1 |STG|The degree of study time for goal object materials |Quantitative |0.060, 0.100, 0.080 | |2 |SCG|The degree of repetition number of user for goal object materials |Quantitative |0.000, 0.100, 0.250 | |3 |STR|The degree of study time of user for related objects with goal object |Quantitative |0.10, 0.15, 0.05 | |4 |LPR|The exam performance of user for related objects with goal object |Quantitative |0.98, 0.10, 0.01 | |5 |PEG|The exam performance of user for goal objects |Quantitative |0.66, 0.56, 0.33 | |6 |UNS|The knowledge level of user (Very Low, Low, Middle, High) |Quantitative |"High", "Middle", "Low" |

Acknowledgement

This data set has been sourced from the Machine Learning Repository of University of California, Irvine User Knowledge Modeling Data Set (UC Irvine). The UCI page mentions the following publication as the original source of the data set: H. T. Kahraman, Sagiroglu, S., Colak, I., Developing intuitive knowledge classifier and modeling of users' domain dependent data in web, Knowledge Based Systems, vol. 37, pp. 283-295, 2013