Find research datasets worth reusing
Search datasets from major research repositories and use ShareScore to quickly assess how well each record supports discovery, access, and reuse.
363
datasets available to search
ShareScore release 0.9.0
Dataset results
363 results for “travel”
Social Processes Initiative in Neurobiology of the Schizophrenia(s) Traveling Human Phantoms
Open the record for dataset details and reuse information.
P-S waves 3D velocity model of Los Humeros area from earthquake based travel-time tomography using CAT3D software (OGS)
<p>The dataset contains the 3D velocity model (VP (m/s), VS (m/s) and VP/VS) obtained from the tomographic inversion of seismological data in the area of Los Humeros (Mexico). The model was performed in the frame of the GEMex project (Mexico‐Europe Cooperation for research of enhanced geothermal systems and super-hot geothermal systems, WP5 ‘Detection of deep structures’, Jousset et al., D5.3, 2019).</p> <p>The inversion used 2661 P arrivals and 2272 S arrivals associated to 395 earthquakes recorded by 37 stations. The picking data was provided by Toledo et al., 2019.</p> <p>The inversion was performed by CAT3D software, a tomographic tool developed by OGS, which uses the SIRT method (Simultaneous Iterative Reconstruction Technique, Stewart, 1993) as inversion algorithm and the ray tracing procedure based on minimum time principle (Böhm et al., 1999). The velocities used as initial model for tomography were provided by the interpolated values obtained from the velocity analysis of four 2D seismic lines acquired inside the same investigated area by the tomographic inversion (See GEMex deliverable D5.3).</p> <p>The 3D velocity model is defined by a 3D grid of 61 nodes in X, 69 nodes in Y and 29 nodes in Z, equally spaced by 250 m in all directions. The total dimensions of the model is 15x17x7 km and the borders positions are (m) (WGS 84/UTM ZONE 14N):</p> <p>Xmin = 655000, Xmax = 670000</p> <p>Ymin = 2168000, Ymax = 2185000</p> <p>Zmin = -3000, Zmax = 4000</p>
Large-scale Ridesharing DARP Instances Based on Real Travel Demand
<p>This repository presents a set of large-scale Dial-a-Ride Problem (DARP) instances. The instances were created as a standardized set of ridesharing DARP problems for the purpose of benchmarking and comparing different solution methods.</p><p>The instances are based on real demand and realistic travel time data from 3 different US cities, Chicago, New York City and Washington, DC. The instances consist of real travel requests from the selected period, positions of vehicles with their capacities and realistic shortest travel times between all pairs of locations in each city.</p><p>The instances and results of two solution methods, the Insertion Heuristic, and the optimal Vehicle-group Assignment method, can be found in the dataset. The dataset and methodology used to create it are described in the paper <a href="https://arxiv.org/abs/2305.18859">Large-scale Ridesharing DARP Instances Based on Real Travel Demand</a>.</p>
Historical Travel and Communications in Finland
<p>This dataset contains a proof-of-concept GIS database of over 29,000 individual historical road polyline segments as a shapefile dataset, covering over 11,000 km<sup>2</sup> in the western Finland from the city of Turku to northern parts of the province of Satakunta. These polylines capture the regional layout of the overland transport infrastructure of late nineteenth and early twentieth century Finland.</p>
Helsinki Region Travel Time Matrix 2018-2023
<p><strong>Introduction</strong></p> <p>This travel time matrix records <strong>travel times</strong> and travel distances for routes between all centroids (N = 13132) of a 250 × 250 m grid over the populated areas in the Helsinki metropolitan area by <strong>walking</strong>, <strong>cycling</strong>, <strong>public transportation</strong>, and <strong>private car</strong>. If applicable, the routes have been calculated for different times of the day (rush hour, midday, off-peak), and assuming different physical abilities (such as walking and cycling speeds), see details below.</p> <p>The grid follows the geometric properties and enumeration of the versatile <a href="https://ckan.ymparisto.fi/dataset/ykr-ruutuaineisto"><em>Yhdyskuntarakenteen seurantajärjestelmä</em> (YKR) grid</a> used in applications across many domains in Finland, and covers the municipalities of Helsinki, Espoo, Kauniainen, and Vantaa in the Finnish capital region.</p> <p> </p> <p><strong>Data formats</strong></p> <p>The data is available in multiple different formats that cater to different requirements, such as different software environments. All data formats share a common set of columns (see below), and can be used interchangeably.</p> <ul> <li><em>Helsinki_Travel_Time_Matrix_2023.csv.zst</em>: comma-separated values (CSV) of all data columns, without geometries. This data set contains all routes in one file, and can be filtered by origin or destination according to the analysis at hand. The data records can also be joined to the geometries as available below. The file is compressed using the <a href="https://facebook.github.io/zstd/">Zstandard algorithm</a>, that many data science libraries, for instance, pandas, <a href="https://pandas.pydata.org/docs/reference/api/pandas.read_csv.html">support transparently, directly, and automatically</a>.</li> <li><em>Helsinki_Travel_Time_Matrix_2023_travel_times.gpkg.zip</em>: an <a href="https://www.ogc.org/standard/geopackage/">OGC GeoPackage standard</a> file containing all data columns <em>and</em> the geometries that relate to the destination grid cell. The data set is delivered as a ZIP archive, which many GIS systems and libraries, e.g., <a href="https://gdal.org/drivers/vector/gpkg.html">GDAL/OGR</a>, <a href="https://docs.qgis.org/">QGIS</a>, or <a href="https://geopandas.org/en/stable/docs/reference/api/geopandas.read_file.html">geopandas</a>, support natively.</li> <li><em>Helsinki_Travel_Matrix_2023_travel_times.csv.zip</em>: a set of 13132 comma-separated value files containing the routes to one destination grid cell each. The files contain all data columns, no geometry, and can be joined to the geometries as available below. Filenames of the individual files within the ZIP archive follow the pattern <em>Helsinki_Travel_Time_Matrix_2023_travel_times_to_5787545.csv</em> where <em>5787545</em> is replaced by the <em>to_id</em> by which the rows in the file are grouped. Use the <em>from_id</em> column to join with the geometries from one of the files below.</li> </ul> <p>Geometry, only:</p> <ul> <li><em>Helsinki_Travel_Time_Matrix_2023_grid.gpkg.zip</em>: an <a href="https://www.ogc.org/standard/geopackage/">OGC GeoPackage standard</a> file containing the geometries and IDs of the grid used in the analysis. This file can be joined both to the <em>from_id</em> and <em>to_id</em> columns of the data files. The data set is delivered as a ZIP archive, which many GIS systems and libraries, e.g., <a href="https://gdal.org/drivers/vector/gpkg.html">GDAL/OGR</a>, <a href="https://docs.qgis.org/">QGIS</a>, or <a href="https://geopandas.org/en/stable/docs/reference/api/geopandas.read_file.html">geopandas</a>, support natively.</li> <li><em>Helsinki_Travel_Time_Matrix_2023_grid.shp.zip</em>: an <a href="https://gdal.org/drivers/vector/shapefile.html">ESRI Shapefile</a> archive containing the geometries and IDs of the grid used in the analysis. This file can be joined both to the <em>from_id</em> and <em>to_id</em> columns of the data files.</li> </ul> <p> </p> <p><strong>Table structure</strong></p> <p><em>from_id</em>: ID number of the origin grid cell <br><em>to_id</em>: ID number of the destination grid cell <br><em>walk_avg</em>: Travel time in minutes from origin to destination by walking at an average speed <br><em>walk_slo</em>: Travel time in minutes from origin to destination by walking slowly <br><em>bike_avg</em>: Travel time in minutes from origin to destination by cycling at an average speed<br><em>bike_fst</em>: Travel time in minutes from origin to destination by cycling fast<br><em>bike_slo</em>: Travel time in minutes from origin to destination by cycling slowly<br><em>pt_r_avg</em>: Travel time in minutes from origin to destination by public transportation in rush hour traffic, walking at an average speed <br><em>pt_r_slo</em>: Travel time in minutes from origin to destination by public transportation in rush hour traffic, walking at a slower speed <br><em>pt_m_avg</em>: Travel time in minutes from origin to destination by public transportation in midday traffic, walking at an average speed <br><em>pt_m_slo</em>: Travel time in minutes from origin to destination by public transportation in midday traffic, walking at a slower speed <br><em>pt_n_avg</em>: Travel time in minutes from origin to destination by public transportation in nighttime traffic, walking at an average speed <br><em>pt_n_slo</em>: Travel time in minutes from origin to destination by public transportation in nighttime traffic, walking at a lower speed <br><em>car_r</em>: Travel time in minutes from origin to destination by private car in rush hour traffic <br><em>car_m</em>: Travel time in minutes from origin to destination by private car in midday traffic <br><em>car_n</em>: Travel time in minutes from origin to destination by private car in nighttime traffic <br><em>walk_d</em>: Distance from origin to destination, in meters, on foot</p> <p> </p> <p><strong>Data for 2013, 2015, and 2018</strong></p> <p>At the Digital Geography Lab, we started computing travel time matrices in 2013. Our methodology has changed in between the iterations, and naturally, there are systematic differences between the iterations' results. Not all input data sets are available to recompute the historical matrices with new methods, however, we were able to repeat the 2018 calculation using the same methods as the 2023 data set, please find the results below, in the same format.</p> <p>For the travel time matrices for 2013 and 2015, as well as for 2018 using an older methodology, please refer to <a href="https://doi.org/10.5281/zenodo.3247563">DOI:10.5281/zenodo.3247563</a>.</p> <p> </p> <p><strong>Methodology</strong></p> <p>Computations were carried out for Wednesday, 15 February, 2023, and Monday, 29 January, 2018, respectively. 'Rush hour' refers to an 1-hour window between 8 and 9 am, 'midday' to 12 noon to 1 pm, and 'nighttime' to 2-3 am.</p> <p>All routes have been calculated using <a href="https://github.com/r5py/r5py">r5py</a>, a Python library making use of the <a href="https://github.com/conveyal/r5">R5</a> engine by <a href="https://conveyal.com">Conveyal</a>, with modifications to consider local characteristics of the Helsinki use case and to inform the computation models from local real-world data sets. In particular, we made the following modifications:</p> <p><em>Walking</em></p> <p>Walking speeds, and in turn walking times, are based on the findings of <a href="https://doi.org/10.1016/j.jtrangeo.2022.103521">Willberg et al., 2023,</a> in which we measured walking speeds of people of different age groups in varying road surface conditions in Helsinki. Specifically, we chose to use the average measured walking speed in summer conditions for <em>walk_avg</em> (as well as the respective <em>pt_*_walk_avg</em>), and the slowest quintile of all measured walker across all conditions for <em>walk_slo</em> (and the respective <em>pt_*_walk_slo</em>).</p> <p><em>Cycling</em></p> <p>Cycling speeds are derived from two input data sets. First, we averaged cycling speeds per network segment from <a href="https://metro.strava.com/">Strava data</a>, and computed a ratio between the speed ridden in each segment and the overall average speed. We then use these ratios to compute fast, slow, and average cycling speeds for each segment, based on the mean overall Strava speed, the mean speeds cycled in the <a href="https://www.hsl.fi/kaupunkipyorat">Helsinki City Bike bike-share system</a>, and the mean between the two.</p> <p>Further, in line with the values observed by <a href="https://blogs.helsinki.fi/saavutettavuus/files/2013/01/Py%C3%B6r%C3%A4ily_osana_joukkoliikennett%C3%A4_kaupunkipy%C3%B6rien_vaikutus_alueiden_saavutettavuuteen_p%C3%A4%C3%A4kaupunkiseudulla.pdf">Jäppinen (2012)</a>, we add a flat 30 seconds each for unlocking and locking the bicycle at the origin and destination.</p> <p><em>Public Transport</em></p> <p>We used public transport schedules in General Transit Feed Specification (GTFS) format published by the <a href="https://www.hsl.fi/hsl/avoin-data">Helsinki Regional Transport Authority</a>, and adjusted the walking speeds (for connections between vehicles, as well as for access and egress to and from public transport stops) using the same methods as described above for <em>walking</em>.</p> <p><em>Private motorcar</em></p> <p>To represent road speeds actually driven in the Helsinki metropolitan region, we used floating car data of a representative sample of the roads in the region to derive the differences between the speed limit and the driven speed on different road classes, and by speed limit, see <a href="https://hdl.handle.net/10138/358181">Perola (2023)</a> for a detailed description of the methodology. Because these per-segment speeds factor in potential waiting times at road crossings, we eliminated turn penalties from R5.</p> <p> </p> <p>Our modifications were carried out in two ways: some changes can be controlled by preparing input data sets in a certain way, or by setting model parameters outside of R5 or r5py. Other modifications required more profound changes to the source code of the R5 engine.</p> <p>You can find a fully patched fork of the R5 engine in the Digital Geography Lab's GitHub repositories at <a href="https://github.com/DigitalGeographyLab/r5">github.com/DigitalGeographyLab/r5</a>. The code that handles input data mangling and model parameter estimations is kept together with the logic to read input parameters and to collate output data, in the repository at <a href="https://github.com/DigitalGeographyLab/Helsinki-Travel-Time-Matrices/">github.com/DigitalGeographyLab/Helsinki-Travel-Time-Matrices</a>.</p>
Data and analysis script for "The (non)effect of personalization in climate texts on credibility of climate scientists: A case study on sustainable travel"
<p>Dataset and analysis script for the article "<strong>The (non)effect of personalization in climate texts on credibility of climate scientists</strong><strong>: A case study on sustainable travel</strong>", under review at Geoscience Communication (https://doi.org/10.5194/egusphere-2024-543)</p>
Catalog of synthetic seismic records from mineral physics and travel-time tables from Waszek et al., 2021, Nature Geoscience
<p>This release is associated with the accepted publication in Nature Geoscience:</p> <p>Waszek L., Tauzin B., Schmerr N., Ballmer M. and Afonso J.C. A poorly mixed mantle transition zone and its thermal state inferred from seismic waves. Nature Geoscience, 2021.</p> <p>This dataset must be used in conjunction with the NoLimit software package (https://zenodo.org/record/5512805).</p> <p>Both the software and dataset allow the prediction of synthetic seismic waveforms for SS and PP-precursors from mineral physics models, as well as their processing for reconstructing the surface of seismic boundaries associated with major mineralogical phase transitions in the Earth’s mantle (namely, the 410-km and 660-km depth discontinuities).</p> <p>For technical reasons (storage and quick access), the catalog is downsampled with respect to the one in Waszek et al. (2021), and it is provided with the HDF5 format. For more advanced applications such as changing mantle composition, or generating waveforms for deeper earthquakes, please contact Benoit Tauzin (benoit.tauzin@univ-lyon1.fr) and Lauren Waszek (lauren.waszek@jcu.edu.au).</p> <p>The dataset includes:</p> <p>* A fixed mantle composition, which is a mechanical mixture of basalt and harzburgite with a fraction of basalt f=0.2.<br> * A downsampled catalog of synthetic waveforms for event depths between 0 and 80 km by step of 10 km (enough for reproducing the processing of observed SS and PP precursors waveforms).<br> * Adiabatic temperature gradients with potential temperature Tpot between 1200 and 2100 K by step of 100 K.</p> <p>This catalog and associated travel-time tables will allow any user to generate synthetic waveforms for any moment tensor, and events within the pre-defined depth interval.<br> </p> <p><strong>How to cite this material?</strong></p> <p>Any use of the datasets or software must refer to:</p> <p>The reference paper: Waszek L., Tauzin B., Schmerr N., Ballmer M., Afonso J.C. A poorly mixed mantle transition zone and its thermal state inferred from seismic waves. Nature Geoscience. 2021.<br> <br> Software: Tauzin, Benoit, & Waszek, Lauren. (2021). NoLiMit MATLAB package v1.0. Non-Linear Bayesian partition Modeling of the Earth's Mantle Transition zone (Version 1). Zenodo. https://doi.org/10.5281/zenodo.5512805<br> <br> Datasets: Tauzin, Benoit, Waszek, Lauren, & Afonso, Juan Carlos. (2021). Catalog of synthetic seismic records from mineral physics and travel-time tables from Waszek et al., 2021, Nature Geoscience (Version 1) [Data set]. Zenodo. https://doi.org/10.5281/zenodo.5512035</p>
DWI Traveling Human Phantom Study
Open the record for dataset details and reuse information.
Travellers baseline, pre and post-questionnaires of the 1st iteration phase
<p>The dataset contains the travellers’ baseline-, pre- and post-questionnaires of the first evaluation phase of the MyCorridor project. The column pre-evaluation indicates whether the respondent took part in the baseline- or pre-questionnaires (Column B-FF). Whereas all respondents were asked to participate in the same post-questionnaire survey (Column FG-MI). The questions in the pre-questionnaires are related to the background of the respondents, mobility wants & needs, online consumer experience, MaaS awareness, MyCorridor platform pre-acceptance, computer literacy, online consumer attitude and behaviour, online shopping needs and wishes and MyCorridor platform pre-acceptance. The questions in the post-questionnaires are related to the evaluation of the app, the interaction experience, the value, usability and acceptance.</p>
Evaluating Nitrate Removal and Travel Times in a Bare Deciduous Forest Soil Using a Tracer-Based Soil Column Experiment
<p> </p> <p>This dataset summarizes the experimental data from a study investigating the relationship between hydrodynamic properties, transport age characteristics (traced using the conservative tracer bromide), and nitrate consumption by native microbial communities in a deciduous forest soil near Lausanne, Switzerland.</p> <h4><strong>Experimental Setup</strong></h4> <ul> <li>Native soil was <strong>collected, sieved, and packed</strong> into homogeneous soil columns (lysimeters) with a porosity of <strong>0.4</strong>.</li> <li>To stimulate microbial activity, the soil underwent <strong>carbon amendment</strong> for several weeks before the experiment.</li> <li>On <strong>June 10, 2021</strong>, a <strong>pulse of bromide and nitrate</strong> (referred to as <strong>SPIKE</strong>) was applied to the bare soil that had undergone carbon amendment.</li> <li>The dataset covers experimental conditions recorded from <strong>May 25, 2021, to August 12, 2021</strong>.</li> </ul> <h4><strong>Included Data & Models</strong></h4> <ol> <li><strong><strong>SPIKE experiment (<strong>pulse of bromide and nitrate</strong>)</strong></strong> <ul> <li> <ul> <li><strong><strong>all other files (see table_of_contents.html and overview.pdf)</strong></strong></li> </ul> </li> </ul> </li> <li> <p><strong>HYDRUS-1D Simulations</strong></p> <ul> <li>The dataset includes HYDRUS-1D simulation files to reproduce <strong>nitrate and bromide breakthrough curves</strong>: <ul> <li><strong>0_Nitrate-double-compartment.zip</strong></li> <li><strong>0_Bromide-double-compartment.zip</strong></li> </ul> </li> </ul> </li> <li> <p><strong>Soil Characterization using Multi-Step Outflow (MSOM) Method</strong></p> </li> </ol> <ul> <li> <ul> <li>Before the main experiment, the <strong>multi-step outflow method</strong> was performed to characterize the soil. The original experimental data was collected at a <strong>15-minute resolution</strong> but has been <strong>upscaled to hourly resolution</strong> to reduce noise and facilitate data handling.<br> <ul> <li><strong>multi-step_outflow_method.csv</strong></li> </ul> </li> </ul> </li> </ul> <ol> <li> <ul> <li>The processed data (at <strong>hourly resolution</strong>) and <strong>HYDRUS-1D inverse modeling simulations</strong> for soil parameter estimation are provided under two configurations: <ul> <li><strong>config_1_MSOM.zip</strong></li> <li><strong>config_2_MSOM.zip</strong></li> </ul> </li> </ul> </li> </ol> <p> </p>
Data for: From pattern to process? Dual travelling waves, with contrasting propagation speeds, best describe a self-organised spatio-temporal pattern in population growth of a cyclic rodent
<p>Centroid data used for the analysis in Roos et al. Eco Lett.</p> <p>Transects, up to 99 m in length (dependent on the field's length), were surveyed in linear stable landscape features (field, track or ditch margins) to estimate vole abundance from November 2011 until September 2017. Each transect was divided into 3 m sections (33 in total) and the presence or absence of one or more signs of vole activity (i.e., latrines by burrows, fresh vegetation clippings, and recent burrow excavations) in each section was noted. The proportion of sections with signs of vole presence per transect was then used as the abundance index. The number of surveys carried out at any time varied adaptively with the perceived risk of an outbreak (according to changes in estimated abundance in previous monitoring surveys).</p> <p>The response variable typically used in all models is proportional growth rate (r_{t,i}, where is the abundance index for site at time (Royama 1992; Berryman 2002). A benefit of using r_{t,i}, rather than ln(N_{t,i}), is that any multiplicative effects of site quality are cancelled out, provided they are constant over time. To calculate r_{t,i}, vole abundance indices are required at the same location in successive time periods (i.e., N_{t,i} and N_{t+1,i}). Given that exact transect locations were rarely reused in successive months, and all transect measurements took place throughout the year rather than discrete seasons, the data had to be aggregated to consistent locations and times to allow growth rate to be calculated. As such, transects were temporally aggregated into a respective yearly quarter (e.g., January to March 2014). Transects were spatially aggregated by sequentially selecting an unassigned transect as a reference point for the ith centroid and assigning all unassigned transects within a 5 km radius to the ith centroid, and repeating until all transects had been allocated (see Figure 2 for a summary of the number of transects assigned to each centroid, centroid locations, and time series of growth rate of each centroid). Once complete, the mean Julian day, X and Y UTM (Universal Transverse Mercator) and the mean index was calculated for all transects assigned to each centroid for each time period. Where a centroid had successive values of N_{t,i} and N_{t+1,i} available, the corresponding proportional growth rate was calculated.</p> <p>A constant of 3.03 was added to N_{t,i} to avoid zero entries (3.03 was the lowest non-zero value of <em>N</em> observed). The final dataset consisted of 3,751 observations.</p>
Supporting Datasets produced in Allen et al. (2018) Global Estimates of River Flow Wave Travel Times and Implications for Low-Latency Satellite Data"
<p><strong>Supporting datasets for Allen et al. (2018) - Global Estimates of River Flow Wave Travel Times and Implications for Low-Latency Satellite Data, <em>Geophysical Research Letters</em>, <a href="https://doi.org/10.1002/2018GL077914">https://doi.org/10.1002/2018GL077914</a></strong></p> <p>The code used to produce these data is available as a Github repository, permanently hosted on Zenodo: <a href="https://doi.org/10.5281/zenodo.1219784">https://doi.org/10.5281/zenodo.1219784</a></p> <p><strong>Abstract</strong></p> <p>Earth-orbiting satellites provide valuable observations of upstream river conditions worldwide. These observations can be used in real-time applications like early flood warning systems and reservoir operations, provided they are made available to users with sufficient lead time. Yet, the temporal requirements for access to satellite-based river data remain uncharacterized for time-sensitive applications. Here we present a global approximation of flow wave travel time to assess the utility of existing and future low-latency/near-real-time satellite products, with an emphasis on the forthcoming SWOT satellite. We apply a kinematic wave model to a global hydrography dataset and find that global flow waves traveling at their maximum speed take a median travel time of 6, 4 and 3 days to reach their basin terminus, the next downstream city and the next downstream dam respectively. Our findings suggest that a recently-proposed ≤2-day latency for a low-latency SWOT product is potentially useful for real-time river applications.</p> <p> </p> <p><strong>Description of repository datasets:</strong></p> <p>1. riverPolylines.zip contains ESRI shapefile polylines of river networks with outputs from main analysis. These continental-scale shapefiles contain the following attributes for each river segment:</p> <ul> <li>"ARCID" : unique identifier for each river segment line, defined as the river reach between river junctions/heads/mouths. The first 10 attributes are taken from Andreadis et al. (2013): https://doi.org/10.5281/zenodo.61758</li> <li>"UP_CELLS" : number of upstream cells (pixels)</li> <li>"AREA" : upstream drainage area (km<sup>2</sup>)</li> <li>"DISCHARGE" : discharge (m<sup>3</sup>/s)</li> <li>"WIDTH" : mean bankfull river width (m)</li> <li>"WIDTH5" : 5th percentile confidence interval bankfull river width (m)</li> <li>"WIDTH95" : 95th percentile confidence interval bankfull river width (m)</li> <li>"DEPTH" : mean bankfull river depth (m)</li> <li>"DEPTH5" : 5th percentile bankfull river depth (m)</li> <li>"DEPTH95" : 95th percentile confidence bankfull river depth (m)</li> <li>"LENGTH_KM" : segment length (km)</li> <li>"ORIG_FID" : original ID of segment</li> <li>"ELEV_M" : lowest elevation of segment (m). Derived from HydroSHEDS 15 sec hydrologically conditioned DEM: https://hydrosheds.cr.usgs.gov/datadownload.php?reqdata=15demg </li> <li>"POINT_X" : longitude of lowest point of segment (WGS84, decimal degrees)</li> <li>"POINT_Y" : latitude of lowest point of segment (WGS84, decimal degrees)</li> <li>"SLOPE" : average slope of segment (m/m)</li> <li>"CITY_JOINS" : an index associated with how likely a city/population center is located on the segment. Population center data from: http://web.ornl.gov/sci/landscan/ and http://www.naturalearthdata.com/downloads/10m-cultural-vectors/10m-populated-places/ </li> <li>"CITY_POP_M" : population of joined city (max N inhabitants) </li> <li>"DAM_JOINSC" : an index associated with how likely a dam is located on the segment. Dam data from Global Reservoir and Dam (GRanD) Database: http://www.gwsp.org/products/grand-database.html </li> <li>"DAM_AREA_S" : surface area of joined dam (m<sup>2</sup>)</li> <li>"DAM_CAP_MC" : volumetric capacity of joined dam (m<sup>3</sup>)</li> <li>"CELER_MPS" : modeled river flow wave celerity (m/s)</li> <li>"PROPTIME_D" : travel time of flow wave along segment (days)</li> <li>"hBASIN" : main basin UID for the hydroBASINS dataset: http://www.hydrosheds.org/page/hydrobasins</li> <li>"GLCC" : Global Land Cover Characterization at segment centroid: https://lta.cr.usgs.gov/glcc/globdoc2_0 </li> <li>"FLOODHAZAR" : flood hazard composite index from the DFO (via NASA Sedac): http://sedac.ciesin.columbia.edu/data/set/ndh-flood-hazard-frequency-distribution</li> <li>"SWOT_TRAC_" : SWOT track density (N overpasses per orbit cycle @ segment centroid). Created using SWOTtrack SWOTtracks_sciOrbit_sept15 polygon shapefile, uploaded here.</li> <li>"UPSTR_DIST" : upstream distance to the basin outlet (km) </li> <li>"UPSTR_TIME" : upstream flow wave travel time to the basin outlet (days)</li> <li>"CITY_UPSTR" : upstream flow wave travel time to the next downstream city (days)</li> <li>"DAM_UPSTR_" : upstream flow wave travel time to the next downstream dam (days)</li> <li>"MC_WIDTH" : mean of Monte Carlo simulated bankfull widths (m)</li> <li>"MC_DEPTH" : mean of Monte Carlo simulated bankfull depths (m)</li> <li>"MC_LENCOR" : mean of Monte Carlo simulated river length correction (km)</li> <li>"MC_LENGTH" : mean of Monte Carlo simulated river length (m)</li> <li>"MC_SLOPE" : mean of Monte Carlo simulated river slope (-)</li> <li>"MC_ZSLOPE" : mean of Monte Carlo simulated minimum slope threshold (m)</li> <li>"MC_N" : mean of Monte Carlo simulated Manning’s n (s/m^(1/3))</li> <li>"CONTINENT" : integer indicating the HydroSHEDS region of shapefile</li> </ul> <p>2. hydrosheds_connectivity.zip contains network connectivity CSVs for river polyline shapefiles. The tables do not contain headers:</p> <ul> <li>Col1: segment unique identifier (UID) corresponding to the ARCID column of the riverPolylines shapefiles</li> <li>Col2: Downstream UID</li> <li>Col3: Number of upstream UIDs</li> <li>Col4 – Col12: Upstream UIDs</li> </ul> <p>3. SWOTtracks_sciOrbit_sept15_density.zip contains a polygon shapefile derived from SWOTtracks_sciOrbit_sept15_completeOrbit containing the sampling frequency of SWOT (number of observations per complete orbit cycle). Polygon attributes correspond to each unique shape formed from overlapping swaths:</p> <ul> <li>FID : unique identifier of each polygon</li> <li>CENTROID_X : polygon centroid longitude (WGS84 - decimal degrees)</li> <li>CENTROID_Y : polygon centroid latitude (WGS84 - decimal degrees)</li> <li>COUNT_count: SWOT sampling frequency (N observations per complete orbit cycle)</li> </ul> <p>4. USGS_gauge_site_information.csv : table containing the list of USGS sites analyzed in the validation and obtained from http://nwis.waterdata.usgs.gov/nwis/dv Header descriptions contained within table. </p> <p>5. validation_gaugeBasedCelerity.zip contains polyline ESRI shapefiles covering North and Central America, where USGS gauges provided gauge-based celerity estimates. These files have FIDs and attributes corresponding to riverPolylines shapefiles described above and also contrain the folllowing fields:</p> <ul> <li>GAUGE_JOIN : an index associated with how likely a gauge is located on the segment. Gauge location information is contained in USGS_gauge_site_information.csv</li> <li>GAUGE_SITE: USGS gauge site number of joined gauge</li> <li>GAUGE_HUC8: which hydrological unit code the gauge is located in</li> <li>OBS_CEL_R: gauge-based correlation score (R). Upstream and downstream gauges were compared via lagged cross correlation analysis. The calculated celerity between the paired gauges were assigned to each segment between the two gauges. If there were multiple pairs of upstream and downstream gauges, the the mean celerity value was assigned, weighted by the quality of the correlation, R. Same weighted mean was applied in assigning R. </li> <li>OBS_CEL_MPS: gauge-based celerity estimate (m/s). </li> </ul> <p>6. tab1_latencies.csv contains data shown in Table 1 of the manuscript.</p> <p>7. figS3S4_monteCarloSim_global_runMeans.csv contains the mean of the Monte Carlo simulation inputs and outputs shown in Figure S3 and Figure S4. Column headers descriptions are given in riverPolylines (dataset #1 above). Some columns have rows with all the same value because these variables did not vary between ensemble runs.</p> <p>8. figS5_travelTimeEnsembleHistograms.zip contains data shown in Figure S5. Each csv corresponds to a figure component:</p> <ul> <li>tabdTT_b.csv : basin outlet travel times for all rivers</li> <li>tabdTT_b_swot.csv : basin outlet travel times for SWOT</li> <li>tabdTT_c.csv : next downstream city travel times for all rivers</li> <li>tabdTT_c_swot.csv : next downstream city travel times for SWOT</li> <li>tabdTT_d.csv : next downstream dam travel times for all rivers</li> <li>tabdTT_d_swot.csv : next downstream dam travel times for SWOT</li> </ul>
Delimiting the Neoproterozoic São Francisco Paleocontinental Block with P-wave travel-time tomography
<p>Tomographic data set for different depths (CSV-files with Longitude, Latitude anda Velocity Perturbation in percentage), Interpreted limit of the São Francisco Paleocontinent and the Abstract for the paper "Delimiting the Neoproterozoic São Francisco paleocontinental block with P-wave travel-time tomography" accepted by Geophysical Journal International.</p>
Dataset for: In-operando microwave scattering-parameter calibrated measurement of a Josephson travelling wave parametric amplifier
<p>Dataset for manuscript "In-operando microwave scattering-parameter calibrated measurement of a Josephson travelling wave parametric amplifier", <a href="https://arxiv.org/abs/2406.03063">arXiv:2406.03063</a></p> <p>Containing the uncalibrated raw measurement data and the calibrated dataset after applying the 8-term error model.</p>
Synthetic multi-day activity-travel schedules for Swedish residents
<div> <h2><strong>About </strong></h2> <p>This dataset contains multi-day activity-travel schedules for <strong>over 263,000 individuals residing in Sweden</strong>, representing approximately <strong>2.6% of country's population</strong>. The individuals and their daily schedules are derived from mobile phone application data covering seven months in 2019. Mobile phone application data, one example of emerging mobility data sources, offers an alternative to other data collection methods. This data is collected by capturing phone users' geographical locations with their consent as they interact with various mobile applications. </p> </div> <div> <p>This open data repository includes activity-travel schedules for each individual <strong>over five simulated average weekdays</strong>, <strong>incorporating daily variability at the individual level</strong>. <strong>Each simulation day provides:</strong> </p> </div> <div> <ul> <li> <p><strong>Anonymized Identifiers:</strong> Unique IDs that link individuals across all simulation days. </p> </li> </ul> </div> <div> <ul> <li> <p><strong>Activity Locations:</strong> Locations for home, work/school and other activities. </p> </li> </ul> </div> <div> <ul> <li> <p><strong>Daily Activity-Travel Schedules:</strong> Detailed information on activity sequence, type, start and end times, and locations. </p> </li> </ul> <p> </p> <div> <h2><strong>Background </strong></h2> </div> <div> <p>The activity-travel schedules were created using a novel generative model that synthesizes individuals' average weekday activity-travel schedules from mobile phone application data. Mobile data provides geographically and population-wise extensive observations over extended periods, offering valuable insights into individuals' whereabouts. However, these datasets often include sampling biases in the population coverage and individual-level data sparsity due to intermittent and irregular phone application activities, from which the underlying geolocation data were passively collected. </p> </div> <div> <p>The generative model combines mobile data with the Swedish national travel survey [1]. The model employs state-of-the-art primary activity identification methods to infer individuals’ primary activity locations, i.e., home and work/school snapped to buildings. The proposed model can generate multiple schedules for each individual, showing activity sequences, types, start/end times and locations, incorporating daily variability in specific schedule attributes. At the individual level, variations occur across all elements of activity schedules, i.e., activity sequences, type, start/end times, and other activity locations, while maintaining the residential and workplace locations. Moreover, the model calculates a weight for each individual based on their residential location and inferred employment status, addressing sampling biases and ensuring a representative sample of the Swedish population. </p> </div> <div> <p>The performance of the generative model is evaluated by comparing its synthesized activity-travel schedules with those from <a href="https://www.sciencedirect.com/science/article/pii/S2352340923003281?via%3Dihub" target="_blank" rel="noopener">the SySMo model</a> [2], large-scale agent-based model of Sweden and with underlying travel survey data. The results demonstrate that the proposed model effectively addresses biases and sparsity in mobile phone application data, resulting in realistic and reliable activity-travel schedules. The pre-print paper "<a href="https://arxiv.org/abs/2410.22386" target="_blank" rel="noopener">Mobile Phone Application Data for Activity Plan Generation</a>" details the model's methodology and evaluation.<br><br></p> <div> <h2><strong>Data Description </strong></h2> </div> <div> <p>The current data covers 5 data files, each showing a simulation day. </p> </div> <div> <div> <div> </div> <table> <tbody> <tr> <td> <div> <div> <p>Column </p> </div> </div> </td> <td> <div> <div> <p>Description </p> </div> </div> </td> <td> <div> <div> <p>Data type </p> </div> </div> </td> <td> <div> <div> <p>Unit </p> </div> </div> </td> </tr> <tr> <td> <div> <div> <p>PId </p> </div> </div> </td> <td> <div> <div> <p>Unique Anonymized Identifiers </p> </div> </div> </td> <td> <div> <div> <p>Integer </p> </div> </div> </td> <td> <div> <div> <p>- </p> </div> </div> </td> </tr> <tr> <td> <div> <div> <p>employment </p> </div> </div> </td> <td> <div> <div> <p>Employment Status (0 = Not Employed, 1 = Employed) </p> </div> </div> </td> <td> <div> <div> <p>Integer </p> </div> </div> </td> <td> <div> <div> <p>- </p> </div> </div> </td> </tr> <tr> <td> <div> <div> <p>weight </p> </div> </div> </td> <td> <div> <div> <p>Weight showing the representativeness of the individuals </p> </div> </div> </td> <td> <div> <div> <p>Float </p> </div> </div> </td> <td> <div> <div> <p>- </p> </div> </div> </td> </tr> <tr> <td> <div> <div> <p>act_id </p> </div> </div> </td> <td> <div> <div> <p>Activity index of each agent </p> </div> </div> </td> <td> <div> <div> <p>Integer </p> </div> </div> </td> <td> <div> <div> <p>- </p> </div> </div> </td> </tr> <tr> <td> <div> <div> <p>act_purpose </p> </div> </div> </td> <td> <div> <div> <p>Activity purpose (work/ home/ other) </p> </div> </div> </td> <td> <div> <div> <p>String </p> </div> </div> </td> <td> <div> <div> <p>- </p> </div> </div> </td> </tr> <tr> <td> <div> <div> <p>act_start </p> </div> </div> </td> <td> <div> <div> <p>Start time of activity in minute (0-1439) </p> </div> </div> </td> <td> <div> <div> <p>Integer </p> </div> </div> </td> <td> <div> <div> <p>minute </p> </div> </div> </td> </tr> <tr> <td> <div> <div> <p>act_end </p> </div> </div> </td> <td> <div> <div> <p>End time of activity in minute (0-1439) </p> </div> </div> </td> <td> <div> <div> <p>Integer </p> </div> </div> </td> <td> <div> <div> <p>minute </p> </div> </div> </td> </tr> <tr> <td> <div> <div> <p>point_x </p> </div> </div> </td> <td> <div> <div> <p>Coordinate X of activity location (SWEREF99TM) </p> </div> </div> </td> <td> <div> <div> <p>Float </p> </div> </div> </td> <td> <div> <div> <p>meter </p> </div> </div> </td> </tr> <tr> <td> <div> <div> <p>point_y </p> </div> </div> </td> <td> <div> <div> <p>Coordinate Y of activity location (SWEREF99TM) </p> </div> </div> </td> <td> <div> <div> <p>Float </p> </div> </div> </td> <td> <div> <div> <p>meter </p> </div> </div> </td> </tr> <tr> <td> <div> <div> <p>point_lat </p> </div> </div> </td> <td> <div> <div> <p>Latitude of activity location (WGS 84) </p> </div> </div> </td> <td> <div> <div> <p>Float </p> </div> </div> </td> <td> <div> <div> <p>degrees </p> </div> </div> </td> </tr> <tr> <td> <div> <div> <p>point_lng </p> </div> </div> </td> <td> <div> <div> <p>Longitude of activity location (WGS 84) </p> </div> </div> </td> <td> <div> <div> <p>Float </p> </div> </div> </td> <td> <div> <div> <p>degrees </p> </div> </div> </td> </tr> </tbody> </table> </div> </div> <div> <h2> </h2> <h2><strong>Privacy Policy </strong></h2> </div> <div> <p>The data underlying this study were purchased from PickWell and are subject to restrictions due to licensing and privacy considerations under the European General Data Protection Regulation (GDPR). Therefore, these data are not publicly available but can be requested for research purposes through commercial access. We adhere to the guidelines established by the Chalmers Institutional Review Board (IRB) following the Swedish Ethical Review Act (2003:460) and GDPR 2016/679. The dataset contains no personal information traceable to individuals. Geolocations in this dataset are synthesized from empirical mobile application data, ensuring privacy while retaining their utility for studying mobility behavior and simulating large-scale travel demand. </p> </div> <div> <p> </p> <h2><strong>Acknowledgement</strong> </h2> </div> <div> <p>This research is funded by the Swedish Research Council Formas (Project Number 2018-01768). The authors acknowledge Sonia Yeh for her intellectual contributions to the study. Additionally, the authors sincerely thank Jorge Gil for providing the mobile phone application data. </p> <div> </div> </div> <p> </p> </div> </div>
First In-Situ Measurements of Travelling Ionospheric Disturbances at 420 km Altitude by the Scintillation Observations and Response of The Ionosphere to Electrodynamics (SORTIE) CubeSat
<p>Companion dataset to the paper entitled "First In-Situ Measurements of Travelling Ionospheric Disturbances at 420 km Altitude by the Scintillation Observations and Response of The Ionosphere to Electrodynamics (SORTIE) CubeSat". The dataset includes the SORTIE CubeSat IVM Level 2 ion density and GPS TEC data used in the study along with the WRF simulation results.</p>
W-Band Traveling Wave Tube Amplifier Based on Planar Slow Wave Structure
<p>Underlying data corresponding to the Journal paper: G. Ulisse and V. Krozer, "W-Band Traveling Wave Tube Amplifier Based on Planar Slow Wave Structure", IEEE Electron Device Letters, vol. 38, no. 1, January 2017.</p>
Open synthetic data on travel and charging demand of battery electric cars: An agent-based simulation on three charging behavior archetypes
<p><strong>Background</strong></p> <p>Battery electric vehicles (BEVs) are crucial for a sustainable transportation system. As more people adopt BEVs, it becomes increasingly important to accurately assess the demand for charging infrastructure. However, much of the current research on charging infrastructure relies on outdated assumptions, such as the assumption that all BEV owners have access to home chargers and the "Liquid-fuel" mental model. To address this issue, we simulate the travel and charging demand on three charging behavior archetypes. We use a large synthetic population of Sweden, including detailed individual characteristics, such as dwelling types (detached house vs. apartment) and activity plans (for an average weekday). This data repository aims to provide the BEV simulation's input, assumptions, and output so that other studies can use them to study sizing and location design of charging infrastructure, grid impact, etc.</p> <p>A journal paper published in Transportation Research Part D: Transport and Environment details the method to create the data (particularly Section 2.2 BEV simulation).</p> <p><a href="https://doi.org/10.1016/j.trd.2023.103645">https://doi.org/10.1016/j.trd.2023.103645</a></p> <p><strong>Methodology</strong></p> <p>This data product is centered on the 1.7 million inhabitants of the Västra Götaland (VG) region, which includes the second largest city in Sweden, Gothenburg. We specifically simulated 284,000 car agents who live in VG, representing 35% of all car users and 18% of the total population in the region. They spend their simulation day (representing an average weekday) in a variety of locations throughout Sweden.</p> <p>This open data repository contains the core model inputs and outputs. The numbers in parentheses correspond to the data sets. We use individual agents' activity plans (1) and travel trajectories from MATSim simulation for the BEV simulation (2), in which we consider overnight charger access (3), car fleet composition referencing the current private car fleet in Sweden (4), and Swedish road network with slope information (5) with realistic BEV charging & discharging dynamics. For the BEV simulation, we tested ten scenarios of charging behavior archetypes and fast charging powers (6). The output includes the time history of travel trajectories and charging of the simulated BEVs across the different scenarios (7).</p> <p><strong>Data description</strong></p> <p>The current data product covers seven data files.</p> <p><strong>(1) Agents' experienced activity plans</strong></p> <p>File name: 1_activity_plans.csv</p> <table> <tbody> <tr> <td> <p><strong>Column</strong></p> </td> <td> <p><strong>Description</strong></p> </td> <td> <p><strong>Data type</strong></p> </td> <td> <p><strong>Unit</strong></p> </td> </tr> <tr> <td> <p>person</p> </td> <td> <p>Agent ID</p> </td> <td> <p>Integer</p> </td> <td> <p>-</p> </td> </tr> <tr> <td> <p>act_id</p> </td> <td> <p>Activity index of each agent</p> </td> <td> <p>Integer</p> </td> <td> <p>-</p> </td> </tr> <tr> <td> <p>deso</p> </td> <td> <p>Zone code of Demographic statistical areas (DeSO)<sup>1</sup></p> </td> <td> <p>String</p> </td> <td> <p>-</p> </td> </tr> <tr> <td> <p>POINT_X</p> </td> <td> <p>Coordinate X of activity location (SWEREF99TM)</p> </td> <td> <p>Float</p> </td> <td> <p>meter</p> </td> </tr> <tr> <td> <p>POINT_Y</p> </td> <td> <p>Coordinate Y of activity location (SWEREF99TM)</p> </td> <td> <p>Float</p> </td> <td> <p>meter</p> </td> </tr> <tr> <td> <p>act_purpose</p> </td> <td> <p>Activity purpose (work, home, other)</p> </td> <td> <p>String</p> </td> <td> <p>-</p> </td> </tr> <tr> <td> <p>mode</p> </td> <td> <p>Transport mode to reach the activity location (car)</p> </td> <td> <p>String</p> </td> <td> <p>-</p> </td> </tr> <tr> <td> <p>dep_time</p> </td> <td> <p>Departure time in decimal hour (0-23.99)</p> </td> <td> <p>Float</p> </td> <td> <p>hour</p> </td> </tr> <tr> <td> <p>trav_time</p> </td> <td> <p>Travel time to reach the activity location</p> </td> <td> <p>String</p> </td> <td> <p>hour:minute:second</p> </td> </tr> <tr> <td> <p>trav_time_min</p> </td> <td> <p>Travel time in decimal minute</p> </td> <td> <p>Float</p> </td> <td> <p>minute</p> </td> </tr> <tr> <td> <p>speed</p> </td> <td> <p>Travel speed to reach the activity location</p> </td> <td> <p>Float</p> </td> <td> <p>km/h</p> </td> </tr> <tr> <td> <p>distance</p> </td> <td> <p>Travel distance between the origin and the destination</p> </td> <td> <p>Float</p> </td> <td> <p>km</p> </td> </tr> <tr> <td> <p>act_start</p> </td> <td> <p>Start time of activity in minute (0-1439)</p> </td> <td> <p>Integer</p> </td> <td> <p>minute</p> </td> </tr> <tr> <td> <p>act_time</p> </td> <td> <p>Activity duration in decimal minute</p> </td> <td> <p>Float</p> </td> <td> <p>minute</p> </td> </tr> <tr> <td> <p>act_end</p> </td> <td> <p>End time of activity in decimal hour (0-23.99)</p> </td> <td> <p>Float</p> </td> <td> <p>hour</p> </td> </tr> <tr> <td> <p>score</p> </td> <td> <p>Utility score of the simulation day given by MATSim</p> </td> <td> <p>Float</p> </td> <td> <p>-</p> </td> </tr> </tbody> </table> <p>1 <a href="https://www.scb.se/vara-tjanster/oppna-data/oppna-geodata/deso--demografiska-statistikomraden/">https://www.scb.se/vara-tjanster/oppna-data/oppna-geodata/deso--demografiska-statistikomraden/</a></p> <p> </p> <p><strong>(2) Travel trajectories</strong></p> <p>File name: 2_input_zip</p> <p>Produced by MATSim simulation, the zip folder contains ten files (events_batch_X.csv.gz, X=1, 2, …, 10) of input events for the BEV simulation. They are the moving trajectories of the car agents in their simulation days.</p> <table> <tbody> <tr> <td> <p><strong>Column</strong></p> </td> <td> <p><strong>Description</strong></p> </td> <td> <p><strong>Data type</strong></p> </td> <td> <p><strong>Unit</strong></p> </td> </tr> <tr> <td> <p>time</p> </td> <td> <p>Time in second in a simulation day (0-86399)</p> </td> <td> <p>Integer</p> </td> <td> <p>Second</p> </td> </tr> <tr> <td> <p>type</p> </td> <td> <p>Event type defined by MATSim simulation<sup>2</sup></p> </td> <td> <p>String</p> </td> <td> <p>-</p> </td> </tr> <tr> <td> <p>person</p> </td> <td> <p>Agent ID</p> </td> <td> <p>Integer</p> </td> <td> <p>-</p> </td> </tr> <tr> <td> <p>link</p> </td> <td> <p>Nearest road link consistent with (5)</p> </td> <td> <p>String</p> </td> <td> <p>-</p> </td> </tr> <tr> <td> <p>vehicle</p> </td> <td> <p>Vehicle ID identical to person</p> </td> <td> <p>Integer</p> </td> <td> <p>-</p> </td> </tr> </tbody> </table> <p><sup>2 </sup>One typical episode of MATSim simulation events: Activity ends (actend) -> Agent’s vehicle enters traffic (vehicle enters traffic) -> Agent’s vehicle moves from previous road segment to its next connected one (left link) -> Agent’s vehicle leaves traffic for activity (vehicle leaves traffic) -> Activity starts (actstart)</p> <p> </p> <p><strong>(3) Overnight charger access</strong></p> <p>File name: 3_home_charger_access.csv</p> <table> <tbody> <tr> <td> <p><strong>Column</strong></p> </td> <td> <p><strong>Description</strong></p> </td> <td> <p><strong>Data type</strong></p> </td> <td> <p><strong>Unit</strong></p> </td> </tr> <tr> <td> <p>person</p> </td> <td> <p>Agent ID</p> </td> <td> <p>Integer</p> </td> <td> <p>-</p> </td> </tr> <tr> <td> <p>home_charger</p> </td> <td> <p>Whether an agent has access to a home garage charger/living in a detached house (0=no, 1=yes)</p> </td> <td> <p>Integer</p> </td> <td> <p>-</p> </td> </tr> </tbody> </table> <p> </p> <p><strong>(4) Car fleet composition</strong></p> <p>File name: 4_car_fleet.csv</p> <table> <tbody> <tr> <td> <p><strong>Column</strong></p> </td> <td> <p><strong>Description</strong></p> </td> <td> <p><strong>Data type</strong></p> </td> <td> <p><strong>Unit</strong></p> </td> </tr> <tr> <td> <p>person</p> </td> <td> <p>Agent ID</p> </td> <td> <p>Integer</p> </td> <td> <p>-</p> </td> </tr> <tr> <td> <p>income_class</p> </td> <td> <p>Income group (0=None, 1=below 180K, 2=180K-300K, 3=300K-420K, 4=above 420K)</p> </td> <td> <p>Integer</p> </td> <td> <p>-</p> </td> </tr> <tr> <td> <p>car</p> </td> <td> <p>Car model class (B=40 kWh, C=60 kWh, D=100 kWh)</p> </td> <td> <p>String</p> </td> <td> <p>-</p> </td> </tr> </tbody> </table> <p> </p> <p>(<strong>5) Road network with slope information</strong></p> <p>File name: 5_road_network_with_slope.shp (5 files in total)</p> <table> <tbody> <tr> <td> <p>Column</p> </td> <td> <p>Description</p> </td> <td> <p>Data type</p> </td> <td> <p>Unit</p> </td> </tr> <tr> <td> <p>length</p> </td> <td> <p>The length of road link</p> </td> <td> <p>Float</p> </td> <td> <p>meter</p> </td> </tr> <tr> <td> <p>freespeed</p> </td> <td> <p>Free speed</p> </td> <td> <p>Float</p> </td> <td> <p>km/h</p> </td> </tr> <tr> <td> <p>capacity</p> </td> <td> <p>Number of vehicles</p> </td> <td> <p>Integer</p> </td> <td> <p>-</p> </td> </tr> <tr> <td> <p>permlanes</p> </td> <td> <p>Number of lanes</p> </td> <td> <p>Integer</p> </td> <td> <p>-</p> </td> </tr> <tr> <td> <p>oneway</p> </td> <td> <p>Whether the segment is one-way (0=no, 1=yes)</p> </td> <td> <p>Integer</p> </td> <td> <p>-</p> </td> </tr> <tr> <td> <p>modes</p> </td> <td> <p>Transport mode (car)</p> </td> <td> <p>String</p> </td> <td> <p>-</p> </td> </tr> <tr> <td> <p>link_id</p> </td> <td> <p>Link ID</p> </td> <td> <p>String</p> </td> <td> <p>-</p> </td> </tr> <tr> <td> <p>from_node</p> </td> <td> <p>Start node of the link</p> </td> <td> <p>String</p> </td> <td> <p>-</p> </td> </tr> <tr> <td> <p>to_node</p> </td> <td> <p>End node of the link</p> </td> <td> <p>String</p> </td> <td> <p>-</p> </td> </tr> <tr> <td> <p>count</p> </td> <td> <p>Aggregated traffic (number of cars travelled per day)</p> </td> <td> <p>Integer</p> </td> <td> <p>-</p> </td> </tr> <tr> <td> <p>slope</p> </td> <td> <p>Slope in percent from -6% to 6%</p> </td> <td> <p>Float</p> </td> <td> <p>-</p> </td> </tr> <tr> <td> <p>geometry</p> </td> <td> <p>LINESTRING (SWEREF99TM)</p> </td> <td> <p>geometry</p> </td> <td> <p>meter</p> </td> </tr> </tbody> </table> <p> </p> <p><strong>(6) Simulation scenarios specifying the parameter sets</strong></p> <p>File name: 6_scenarios.txt</p> <table> <tbody> <tr> <td> <p><strong>Parameter set</strong></p> <p><strong>(paraset)</strong></p> </td> <td> <p><strong>Strategy 1</strong></p> </td> <td> <p><strong>Strategy 2</strong></p> </td> <td> <p><strong>Strategy 3</strong></p> </td> <td> <p><strong>Fast charging power (kW)</strong></p> </td> <td> <p><strong>Minimum parking time for charging (min)</strong></p> </td> <td> <p><strong>Intermediate charging power (kW)</strong></p> </td> </tr> <tr> <td> <p>0</p> </td> <td> <p>0.2</p> </td> <td> <p>0.2</p> </td> <td> <p>0.9</p> </td> <td> <p>150</p> </td> <td> <p>5</p> </td> <td> <p>22</p> </td> </tr> <tr> <td> <p>1</p> </td> <td> <p>0.2</p> </td> <td> <p>0.2</p> </td> <td> <p>0.9</p> </td> <td> <p>50</p> </td> <td> <p>5</p> </td> <td> <p>22</p> </td> </tr> <tr> <td> <p>2</p> </td> <td> <p>0.3</p> </td> <td> <p>0.3</p> </td> <td> <p>0.9</p> </td> <td> <p>150</p> </td> <td> <p>5</p> </td> <td> <p>22</p> </td> </tr> <tr> <td> <p>3</p> </td> <td> <p>0.3</p> </td> <td> <p>0.3</p> </td> <td> <p>0.9</p> </td> <td> <p>50</p> </td> <td> <p>5</p> </td> <td> <p>22</p> </td> </tr> </tbody> </table> <p> </p> <p><strong>(7) Time history of travel trajectories and charging of the simulated BEVs</strong></p> <p>File name: 7_output.zip</p> <p>Produced by the BEV simulation, the zip folder contains four files (parasetX.csv.gz, X=1, 2, 3, 4) corresponding to the four parameter sets specified in (6). They are the moving trajectories of the car agents with simulated energy and charging time history in their simulation days.</p> <table> <tbody> <tr> <td> <p><strong>Column</strong></p> </td> <td> <p><strong>Description</strong></p> </td> <td> <p><strong>Data type</strong></p> </td> <td> <p><strong>Unit</strong></p> </td> </tr> <tr> <td> <p>person</p> </td> <td> <p>Agent ID</p> </td> <td> <p>Integer</p> </td> <td> <p>-</p> </td> </tr> <tr> <td> <p>home_charger</p> </td> <td> <p>Whether an agent has access to a home garage charger/living in a detached house (0=no, 1=yes)</p> </td> <td> <p>Integer</p> </td> <td> <p>-</p> </td> </tr> <tr> <td> <p>car</p> </td> <td> <p>Car model class (B=40 kWh, C=60 kWh, D=100 kWh)</p> </td> <td> <p>String</p> </td> <td> <p>-</p> </td> </tr> <tr> <td> <p>seq</p> </td> <td> <p>Sequence ID of time history by agent</p> </td> <td> <p>Integer</p> </td> <td> <p>-</p> </td> </tr> <tr> <td> <p>time</p> </td> <td> <p>Time (0-86399)</p> </td> <td> <p>Integer</p> </td> <td> <p>Second</p> </td> </tr> <tr> <td> <p>purpose</p> </td> <td> <p>Valid for activities (home, work, school, other)</p> </td> <td> <p>String</p> </td> <td> <p>-</p> </td> </tr> <tr> <td> <p>type</p> </td> <td> <p>Event type defined by MATSim simulation</p> </td> <td> <p>String</p> </td> <td> <p>-</p> </td> </tr> <tr> <td> <p>link</p> </td> <td> <p>Link ID (link_id in File 5)</p> </td> <td> <p>String</p> </td> <td> <p>-</p> </td> </tr> <tr> <td> <p>distance_driven</p> </td> <td> <p>Cumulative driven distance in the simulation day</p> </td> <td> <p>Float</p> </td> <td> <p>km</p> </td> </tr> <tr> <td> <p>energy_1</p> </td> <td> <p>Energy consumed while driving (-) or charging (+) (Strategy 1)</p> </td> <td> <p>Float</p> </td> <td> <p>kWh</p> </td> </tr> <tr> <td> <p>energy_2</p> </td> <td> <p>Energy consumed while driving (-) or charging (+) (Strategy 2)</p> </td> <td> <p>Float</p> </td> <td> <p>kWh</p> </td> </tr> <tr> <td> <p>energy_3</p> </td> <td> <p>Energy consumed while driving (-) or charging (+) (Strategy 3)</p> </td> <td> <p>Float</p> </td> <td> <p>kWh</p> </td> </tr> <tr> <td> <p>charger_1</p> </td> <td> <p>Power rating of the charger (Strategy 1)</p> </td> <td> <p>Float</p> </td> <td> <p>kW</p> </td> </tr> <tr> <td> <p>charger_2</p> </td> <td> <p>Power rating of the charger (Strategy 2)</p> </td> <td> <p>Float</p> </td> <td> <p>kW</p> </td> </tr> <tr> <td> <p>charger_3</p> </td> <td> <p>Power rating of the charger (Strategy 3)</p> </td> <td> <p>Float</p> </td> <td> <p>kW</p> </td> </tr> <tr> <td> <p>soc_1</p> </td> <td> <p>State of charge (0-1, Strategy 1)</p> </td> <td> <p>Float</p> </td> <td> <p>-</p> </td> </tr> <tr> <td> <p>soc_2</p> </td> <td> <p>State of charge (0-1, Strategy 2)</p> </td> <td> <p>Float</p> </td> <td> <p>-</p> </td> </tr> <tr> <td> <p>soc_3</p> </td> <td> <p>State of charge (0-1, Strategy 3)</p> </td> <td> <p>Float</p> </td> <td> <p>-</p> </td> </tr> </tbody> </table> <p> </p>
Data of the INFORMS Journal on Computing paper: Routing replenishment workers: The prize collecting traveling salesman problem in scattered storage warehouses
<p>In what follows, you will find data of the paper:<br> "Routing replenishment workers: The prize collecting traveling salesman problem in scattered storage warehouses" published in INFORMS Journal on Computing</p> <p>List of files:<br> - Computational_results_BB_NN_RW_CPLEX.xlsx: Excel file that gives all results<br> - instance_gen.cc: Instance generator<br> - instances.zip: compressed file of all instances that are sorted by Sections. It additionally includes the generator<br> - Makefile: Makefile for compiling/debugging, i.e., "make all" or "make debug" do the jobs<br> - MersenneTwister.h: needed by schedule_finder.cc<br> - results_Section_5_1.zip: compressed file of all output files of Section 5.1<br> - results_Section_5_2.zip: compressed file of all output files of Section 5.2<br> - results_Section_5_3.zip: compressed file of all output files of Section 5.3<br> - schedule_finder.cc: Main program containing the B&B, the S-shape, and Nearest Neighbor procedure (see details for customizing the parameters at the top of this file)<br> - valgrind_debug.txt: Only contains the used debug command</p> <p>instances/instance_gen.cc generates a problem instance in file problems.txt<br> The structure of the these problem files is the following:<br> /*<br> NE Total number of experiments given by the currently considered file<br> -2 Separator<br> EXPGRP Index of the current experiment group the current experiment belong to<br> N Number of vacant positions in the warehouse<br> M Number of requests to be stored by the tour<br> P Number of pickers to be scheduled in the warehouse<br> A Number of vertical aisles<br> B Number of horizontal (cross) aisles<br> L_A Length of each vertical aisle<br> L_B Length of each cross aisle<br> UF_VA Up-factor of each vertical aisle (A values)<br> DF_VA Down- factor of each vertical aisle (A values)<br> UF_CA Up-factor of each cross aisle (B values)<br> DF_CA Down- factor of each cross aisle (B values)<br> x_pos_vertical_aisle x-position of vertical aisle (A values)<br> y_pos_cross_aisle y-position of cross aisle (B values)<br> warehouse_graph values For each node of the warehouse graph all entries (15 each) are given (total_number_of_warehouse_graph_nodes*15)<br> FS << warehouse_graph[curr_node].free_position << " " << endl;<br> FS << warehouse_graph[curr_node].depot_node << " " << endl;<br> FS << warehouse_graph[curr_node].vertical_aisle << " " << endl;<br> FS << warehouse_graph[curr_node].cross_aisle << " " << endl;<br> FS << warehouse_graph[curr_node].pred_cross_aisle << " " << endl;<br> FS << warehouse_graph[curr_node].succ_cross_aisle << " " << endl;<br> FS << warehouse_graph[curr_node].pred_vertical_aisle << " " << endl;<br> FS << warehouse_graph[curr_node].succ_vertical_aisle << " " << endl;<br> FS << warehouse_graph[curr_node].pred_cross_aisle_dist << " " << endl;<br> FS << warehouse_graph[curr_node].succ_cross_aisle_dist << " " << endl;<br> FS << warehouse_graph[curr_node].pred_vertical_aisle_dist << " " << endl;<br> FS << warehouse_graph[curr_node].succ_vertical_aisle_dist << " " << endl;<br> FS << warehouse_graph[curr_node].region << " " << endl;<br> FS << warehouse_graph[curr_node].x_position << " " << endl;<br> FS << warehouse_graph[curr_node].y_position << " " << endl;<br> shortest_path_distance For each combination of nodes (i.e., for total_number_of_warehouse_graph_nodes_square combinations) the distance<br> shortest_path_length_including_start_and_end For each combination of nodes (i.e., for total_number_of_warehouse_graph_nodes_square combinations) the number of visited nodes<br> shortest_path_visited_nodes For each combination of nodes (i.e., for total_number_of_warehouse_graph_nodes_square combinations) the detailed path (length is respectively given by shortest_path_length_including_start_and_end)<br> dd_free_position For each free position and the depot (here with index N) the due date is transferred (N+1 values) (only relevant for the extended problem, is ignored here)<br> weight_of_free_position For each free position and the depot (here with index N) the weight is transferred (N+1 values) (only relevant for the extended problem, is ignored here)<br> capacity_of_free_position For each free position the storage capacity transferred (N values)<br> -2 Separator indicating the end of an instances<br> -3 Separator indicating the end of all experiments (i.e., indicating the end of the file)<br> */</p> <p>output files (results_Section_5_1.zip/results_Section_5_2.zip/results_Section_5_3.zip):<br> results_BB_NXXX_MYYY_A10_B05: Output file of applying B&B<br> results_RW_NXXX_MYYY_A10_B05: Output file of applying s-shape random walk<br> results_NN_NXXX_MYYY_A10_B05: Output file of applying nearest neighbor</p> <p>In these files you find all outputs of schedule_finder.cc. <br> Among others, you will find the generated tour schedules (for Experiment with index I) in the output files by searching the phrase: "Experiment I completed with result="<br> or for the next Experiment " completed with result="</p> <p>Example (results_BB_N030_M150_A10_B05.txt, experiment 0, the tardiness values are to be ignored, see comments in schedule_finder.cc)<br> Pos 0 depot node with index 80 Number of stored items 0 CT 0 No tardiness<br> Pos 1 position 27 Number of stored items 4 Current accumulated number of stored items 4 CT 163 DD 5629 No additional tardiness<br> Pos 2 position 28 Number of stored items 5 Current accumulated number of stored items 9 CT 399 DD 2962 No additional tardiness<br> Pos 3 position 29 Number of stored items 4 Current accumulated number of stored items 13 CT 670 DD 12631 No additional tardiness<br> Pos 4 position 26 Number of stored items 5 Current accumulated number of stored items 18 CT 840 DD 10142 No additional tardiness<br> Pos 5 position 23 Number of stored items 7 Current accumulated number of stored items 25 CT 1134 DD 6000 No additional tardiness<br> Pos 6 position 22 Number of stored items 4 Current accumulated number of stored items 29 CT 1170 DD 6396 No additional tardiness<br> Pos 7 position 16 Number of stored items 5 Current accumulated number of stored items 34 CT 1448 DD 8962 No additional tardiness<br> Pos 8 position 11 Number of stored items 10 Current accumulated number of stored items 44 CT 1674 DD 6336 No additional tardiness<br> Pos 9 position 0 Number of stored items 10 Current accumulated number of stored items 54 CT 2062 DD 1141 Additional tardiness 921<br> Pos 10 position 2 Number of stored items 9 Current accumulated number of stored items 63 CT 2201 DD 7742 No additional tardiness<br> Pos 11 position 4 Number of stored items 5 Current accumulated number of stored items 68 CT 2407 DD 4846 No additional tardiness<br> Pos 12 position 3 Number of stored items 5 Current accumulated number of stored items 73 CT 2717 DD 2316 Additional tardiness 401<br> Pos 13 position 1 Number of stored items 8 Current accumulated number of stored items 81 CT 2876 DD 9917 No additional tardiness<br> Pos 14 position 6 Number of stored items 3 Current accumulated number of stored items 84 CT 3073 DD 7299 No additional tardiness<br> Pos 15 position 5 Number of stored items 8 Current accumulated number of stored items 92 CT 3144 DD 6152 No additional tardiness<br> Pos 16 position 8 Number of stored items 6 Current accumulated number of stored items 98 CT 3337 DD 3705 No additional tardiness<br> Pos 17 position 12 Number of stored items 9 Current accumulated number of stored items 107 CT 3452 DD 7622 No additional tardiness<br> Pos 18 position 13 Number of stored items 4 Current accumulated number of stored items 111 CT 3522 DD 7833 No additional tardiness<br> Pos 19 position 14 Number of stored items 5 Current accumulated number of stored items 116 CT 3647 DD 9877 No additional tardiness<br> Pos 20 position 19 Number of stored items 1 Current accumulated number of stored items 117 CT 3922 DD 2905 Additional tardiness 1017<br> Pos 21 position 20 Number of stored items 5 Current accumulated number of stored items 122 CT 3923 DD 2538 Additional tardiness 1385<br> Pos 22 position 21 Number of stored items 7 Current accumulated number of stored items 129 CT 3976 DD 2769 Additional tardiness 1207<br> Pos 23 position 18 Number of stored items 10 Current accumulated number of stored items 139 CT 4173 DD 3552 Additional tardiness 621<br> Pos 24 position 25 Number of stored items 4 Current accumulated number of stored items 143 CT 4482 DD 11710 No additional tardiness<br> Pos 25 position 24 Number of stored items 7 Current accumulated number of stored items 150 CT 4509 DD 10599 No additional tardiness<br> Pos 26 visiting the node with index 80 Number of stored items 0 CT 4710 DD 10893 No additional tardiness<br> opt_makespan=4710 opt_total_tardiness=5552<br> TSP_procedure returned value 4710<br> Experiment 0 completed with result=3<br> BFS Branch&Bound report: Consumed time: 1</p> <p>Copied from schedule_finder.cc:<br> Note that the procedure used as a solution procedure in the paper is int TSP_procedure(struct bb_node *curr_bb_node, int version)</p> <p>It is called by BB_procedure() as a subroutine for computing a lower bound value of an extended problem<br> (for instance, this extended problem additionally covers due dates. Therefore, due dates are also part of the problem instances, but can be ignored)<br> Specifically, TSP_procedure(struct bb_node *curr_bb_node, int version) is called once by lb_computation()</p>
Traveller pre and post-questionnaires of mainstream and in depth users of the 2nd iteration phase
<p>The dataset contains the travellers’ pre- and post-questionnaires of the second evaluation phase in the MyCorridor project, which was a semi-real-world test. Each spreadsheet indicates the source of the data (pre, post, mainstream or in depth users). The questions are related to easiness to use the app, usefulness of the App, social desirability, attitude towards public transport, sharing modes and general mind sets, perceived accessibility to local transport, perceived accessibility to innovative mobility services and perceived overall trustworthiness, safety and security when using transport services.</p>
ScienceDex guides
Understand access before you commit
These curated guides explain access requirements, typical timelines, costs, and reuse considerations for widely used research datasets.
Allen Brain Atlas
Allen Brain Atlas is an Allen Institute collection of brain map atlases, datasets, APIs, and analysis tools covering mouse, human, and non-human primate brain resources.
Annotated Behaviour and Observability Dataset (ABODe)
ABODe is a University of Edinburgh DataShare dataset for behavior classification in group-housed mice using home-cage video, identities, bounding boxes, ground-plate positions, and annotator labels.
DANDI Archive for NWB datasets
DANDI is a BRAIN Initiative archive for publishing and sharing neurophysiology data, including electrophysiology, optophysiology, and behavioral data packaged as NWB and related standards.
International Brain Laboratory public data
The International Brain Laboratory public data releases expose standardized mouse decision-making experiments, including Neuropixels recordings, widefield calcium imaging, behavior, and session metadata accessed through the ONE API.
OpenNeuro
OpenNeuro is a free, open platform for sharing neuroimaging datasets, with public search, dataset pages, and download paths for web, S3, DataLad, and the OpenNeuro CLI.