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.
814
datasets available to search
ShareScore release 0.9.0
Dataset results
814 results for “Routing”
GSR - Global Sea Routes, dataset
<p>GSR - Global Sea Routes, P. I. Guido Abbattista, 2021, http://gsr.nodegoat.net/ (CC BY-NC-ND 4.0). Dataset 1.0.0, 25 August 2022.</p>
Global monthly discharge dataset, derived from dynamical 1-D water-energy routing model (DynWat) at 10 km spatial resolution
<pre>Global 10km spatial resolution discharge dataset at the global scale for all major rivers, lakes and reservoirs. Data are provided at a monthly temporal resolution.</pre>
Vehicle Routing Problem with Drones Instances
<p>The following instances are originally presented in the paper <em>An Adaptive Large Neighborhood Search Metaheuristic for the Vehicle Routing Problem with Drones</em>, written by David Sacramento Lechado, David Pisinger and Stefan Røpke, and published in <em>Transportation Research Part C: Emerging Technologies</em>.</p> <p>The data correspond to 112 instances corresponding to different scenarios for the Vehicle Routing Problem with Drones. Each instance is named <strong>n.m.t</strong>, where <strong>n</strong> is the number of customers in the scenario, <strong>m</strong> is the dimension of the grid, and <strong>t</strong> is the generic name of the scenario. Moreover, the data additionally contains 10 clustered instances, named <strong>n.m.c.t</strong>, where <strong>c</strong> refers to the cluster-feature of the instance, 100 instances for the sensitivity analysis, named <strong>n.m.s.t</strong>, where <strong>s</strong> stands for sensitivity, and 375 instances for the experiments with drone savings as function of grid size, named <strong>n.m.g.t</strong>.</p> <p>The first line of each instance file indicates the number of customers in the specific instance. The second line is the header for the characteristics of each customer, where it is written <em>Coordinate X, Coordinate Y</em> and <em>Demand. </em>The following provides the previous information for each customer in the instance.</p> <p>Finally, there is an extra file, named <strong>RouteData,</strong> which provides information about the value of the parameters in the main configuration of the problem. These parameters are:</p> <ul> <li><strong>TruckSpeed: </strong>Speed in mpm (miles per minute) of the trucks.</li> <li><strong>DroneSpeed: </strong>Speed in mpm of the drones.</li> <li><strong>TruckCapacityWithDrones: </strong>Maximum capacity of the trucks for the drone-truck scenario.</li> <li><strong>TruckCapacityWithoutDrones: </strong>Maximum capacity of the trucks for the truck-only scenario.</li> <li><strong>DroneCapacity:</strong> Maximum allowed weight a drone can carry.</li> <li><strong>ServiceTimeTruck:</strong> Required service time for a truck to service a customer.</li> <li><strong>ServiceTimeDrone:</strong> Required service time for a drone to service a customer.</li> <li><strong>Endurance: </strong>Maximum flight endurance of the battery of the drone.</li> <li><strong>MaximumDriveTime: </strong>Maximum duration time of the routes.</li> <li><strong>LaunchTime: </strong>Required time for launching a drone.</li> <li><strong>RecoveryTime: </strong>Required time for recovering a drone.</li> <li><strong>CostFactor:</strong> Corresponding parameter for computing the cost for a truck for traversing arc (i,j), given by fuel price (euro/liter), consumption rate (liter/km) and miles converter (km/miles).</li> <li><strong>DroneFactor: </strong>Corresponding parameter for computing the cost for a drone for traversing arc (i,j) with respect to the truck cost.</li> </ul> <p> </p>
Mulit-Criteria Power Line Routeing GIS_dataset 2
<p>The dataset presented here contains GIS (Geographic Information System) data relevant for infrastructure projects, specifically development of DC grid.</p> <p>The data has been sourced from a range of sources and proceeded to be compatible for combination and analysis. For each data set included, the conversion of the original data into a 500m grid in EPSG 31468 projection with the raster calculator implemented in QGIS has been carried out.</p> <ul> <li>Elevation</li> </ul> <p>The elevation data originate from the EEA [1]. The resolution of the original data corresponds to about 25m and is available in raster format. The bilinear resampling method was used to determine the values of the new grid fields.</p> <ul> <li>Landscape quality assessment</li> </ul> <p>Uniform assessment per grid field between 0 (low) and 10 (high) derived from the original data set of [2] with a total of information on 44 primary land use types based on the assessment criteria of [3]. The data set used here is the CLC2012 which refers to the reference year 2012. </p> <ul> <li>Population density</li> </ul> <p>Source of population density is a raster grid provided by the [4] which expresses the number of people per pixel with a resolution of 250m x 250m. The base year for population data is 2015.</p> <ul> <li>Protected areas</li> </ul> <p>Reduction of data from [5] to continental Europe and change of projection.</p> <ul> <li>Slope</li> </ul> <p>Derived from elevation data based on [1]. The slope is calculated by the tilt angle for each raster cell in degrees based on the first-order derivation. </p> <p> </p>
Global monthly water temperature dataset, derived from dynamical 1-D water-energy routing model (DynWat) at 10 km spatial resolution
<pre>Global 10km spatial resolution water temperature dataset at the global scale for all major rivers, lakes and reservoirs. Data are provided at a monthly temporal resolution.</pre> <p>V1.1 update includes a improved version of the model removing some initial spikes related to rapid ice melt and streams that fall dry. The record has been reduced from 1981 tot 2014 to remove potential spinup impacts.</p> <p>The 1960-2010 data from v1.0 can be used for the earlier years.</p> <p>Consistent forcing is used for both time periods to remove potential biases that might occur otherwise.</p>
Dataset defining representative route network for GLOWOPT market segments
<p>For calculating the GLOWOPT representative route network, a forecast model chain was used. The model was calibrated with 2019 flight movement data (unimpeded by COVID-19) and provided forecasted aircraft movements from the year 2019 (~2020) to 2050 in 5 years intervals.</p> <p>Two formats of datasets are generated with the results of the forecast model chain, a csv file format and 4-dimensional array supported with MATLAB (.mat).</p> <p><strong>CSV Datasets</strong></p> <p>For each forecasted year a csv file is generated with the information on the origin-destination (OD) airports IATA codes, region, latitude and longitude of OD pair, representative aircraft type along with the aircraft category , the average load factor and finally, the distance between the OD pair. The airports worldwide are sub-dived into nine regions namely Africa, Asia, Caribbean, Central America, Europe, Middle East, North America, Oceania and South America. There are total of seven datasets, one for each forecasted year i.e. for years 2019 (~2020), 2025, 2030, 2035, 2040, 2045 and 2050.</p> <p><strong>Description of the data labels:</strong></p> <p><strong>Origin-</strong> Origin airport IATA code</p> <p><strong>Origin_Region-</strong> Region of the Origin Airport</p> <p><strong>Origin_Latitude-</strong> Latitude of the Origin Airport</p> <p><strong>Origin_Longitude-</strong> Longitude of the Origin Airport</p> <p><strong>Destination-</strong> Destination airport IATA code</p> <p><strong>Destination_Region-</strong> Region of the Destination Airport</p> <p><strong>Destination_Latitude-</strong> Latitude of the Destination Airport</p> <p><strong>Destination_Longitude-</strong> Longitude of the Destination Airport</p> <p><strong>AcType- </strong>Representative aircraft type</p> <p><strong>Load_Factor- </strong>Average load factor per flight</p> <p><strong>Yearly_Frequency-</strong> Total aircraft movements per annum</p> <p><strong>RefACType-</strong> Aircraft Category based on number of seats (Category 6 represents aircraft with seats 252-301 and category 7 represents aircraft with seats greater than 302.)</p> <p><strong>Distance-</strong> Great circle distance between Origin and Destination in Km.</p> <p> </p> <p><strong>MATLAB Datasets</strong></p> <p>The dataset generated with MATLAB is a 4-dimensional array with the extension *.mat. The first dimension is the region of the origin airport and subsequently the second dimensions contains the region of the destination airport. The third and fourth dimension are the aircraft category based on seat numbers and the categorized great circle distances. The information received therein is a 1X1 cell with the IATA codes of the OD pairs, frequency and great circle distance in Km.</p> <p>The 4D array is categorised such that the user can select the route segment specific to a region or a combination of regions. The range categorisation in combination with an aircraft category additionally offers the user the possibility to select routes depending on their great circle distances. The ranges are categorised to represent very short range (0-2000 km), short range (2000-6000 km), medium range (6000-10000 km) and long range (10000 – 15000 km).</p> <p><strong>Indexing based on the categorisation of the 4D array dataset</strong> - Refer to file 'Indexing_MAT_Dataset.PNG'</p> <p>For example:</p> <p>To derive the OD pairs and yearly frequency of aircraft movements for routes which originate from Europe and are destined to Asia, operated with category 6 aircraft type and are separated by distances between 10,000 to 15,000 km:</p> <p><strong>In MATLAB (Indexing based on file </strong> 'Indexing_MAT_Dataset.PNG' <strong>): </strong></p> <p><strong>Route_Network (5,2,1,4), </strong></p> <p>Description on Index:</p> <p>5 – Europe: Origin Region </p> <p>2 – Asia: Destination Region</p> <p>1– Category 6: Aircraft Type</p> <p>4 – 10000-15000 km: Range</p>
Traffic network routing index for the Czech Republic
<p><strong>Graph representation of road network of the Czech Republic</strong></p> <p>This dataset contains graph of the entire Czech road network. The data are derived from the Open Street Map project and stored in a HDF5 file. The file contains graph topology and metadata for edges and vertices. </p> <p>Spatial index is also included for the purpose of point snapping and other spatial queries. The spatial index is stored in a SQLite file with SpatiaLite extension.</p> <p>Creation of this dataset has been supported by the <a href="http://antarex-project.eu">Antarex project</a>.</p> <p><strong>Routing Index in HDF5</strong></p> <p><strong>File: </strong><a href="/api/files/f1fb6db8-a2e2-425b-b15e-8e401eb22d44/CZE-1528295206-proc-20180724134457.hdf?versionId=3294ae0b-c3b2-4155-ad36-311d2bb06ed9">CZE-1528295206-proc-20180724134457.hdf</a></p> <p>The index is divided into parts according to geographical boundaries defined by country borders. In this case it contains only single part - CZE. This information along with the creation time is stored as an attribute in the root group of the file.</p> <p>The graph topology is stored in the following way. Nodes have assigned a row index in the edges dataset which points to an outbound edge plus a number of the subsequent edges which are also output to this node. The edge metadata are stored in the EdgeData dataset to avoid redundancy. NodeMap dataset provides a convenient way to query nodes based on their uniqe identifiers.</p> <p><strong>File structure:</strong></p> <pre><code class="language-javascript">HDF5 "CZE-1528295206-proc-20180724134457.hdf" { GROUP "/" { GROUP "Index" { ATTRIBUTE "CreationTime" { DATATYPE H5T_STD_I64LE DATASPACE SCALAR DATA { (0): 1535451896 } } ATTRIBUTE "PartsCount" { DATATYPE H5T_STD_I32LE DATASPACE SCALAR DATA { (0): 1 } } ATTRIBUTE "PartsInfo" { DATATYPE H5T_COMPOUND { H5T_STRING { STRSIZE 4; STRPAD H5T_STR_NULLPAD; CSET H5T_CSET_ASCII; CTYPE H5T_C_S1; } "id"; H5T_STD_I64LE "nodeCount"; H5T_STD_I64LE "edgeCount"; } DATASPACE SIMPLE { ( 1 ) / ( 1 ) } DATA { (0): { "CZE\000", 904085, 2223222 } } } GROUP "CZE" { ATTRIBUTE "PartInfo" { DATATYPE H5T_STRING { STRSIZE 4; STRPAD H5T_STR_NULLPAD; CSET H5T_CSET_ASCII; CTYPE H5T_C_S1; } DATASPACE SCALAR DATA { (0): "CZE\000" } } DATASET "Edges" { DATATYPE H5T_COMPOUND { H5T_STD_I32LE "edgeId"; H5T_STD_I32LE "nodeIndex"; H5T_STD_I32LE "computed_speed"; H5T_STD_I32LE "length"; H5T_STD_I32LE "edgeDataIndex"; } DATASPACE SIMPLE { ( 2223222, 1 ) / ( H5S_UNLIMITED, H5S_UNLIMITED ) } } DATASET "Nodes" { DATATYPE H5T_COMPOUND { H5T_STD_I32LE "id"; H5T_STD_I32LE "latitudeInt"; H5T_STD_I32LE "longtitudeInt"; H5T_STD_U8LE "edgeOutCount"; H5T_STD_I32LE "edgeOutIndex"; H5T_STD_U8LE "edgeInCount"; } DATASPACE SIMPLE { ( 904085, 1 ) / ( H5S_UNLIMITED, H5S_UNLIMITED ) } } } DATASET "EdgeData" { DATATYPE H5T_COMPOUND { H5T_STD_I32LE "id"; H5T_STD_U8LE "speed"; H5T_STD_U8LE "funcClass"; H5T_STD_U8LE "lanes"; H5T_STD_U8LE "vehicleAccess"; H5T_STD_U16LE "specificInfo"; H5T_STD_U16LE "maxWeight"; H5T_STD_U16LE "maxHeight"; H5T_STD_U8LE "maxAxleLoad"; H5T_STD_U8LE "maxWidth"; H5T_STD_U8LE "maxLength"; H5T_STD_I8LE "incline"; } DATASPACE SIMPLE { ( 2838, 1 ) / ( H5S_UNLIMITED, H5S_UNLIMITED ) } } DATASET "NodeMap" { DATATYPE H5T_COMPOUND { H5T_STD_I32LE "nodeId"; H5T_STRING { STRSIZE 4; STRPAD H5T_STR_NULLPAD; CSET H5T_CSET_ASCII; CTYPE H5T_C_S1; } "partId"; H5T_STD_I32LE "nodeIndex"; } DATASPACE SIMPLE { ( 904085, 1 ) / ( H5S_UNLIMITED, H5S_UNLIMITED ) } } } } }</code></pre> <p><strong>Spatial index</strong></p> <p><strong>File: </strong><a href="https://zenodo.org/api/files/f1fb6db8-a2e2-425b-b15e-8e401eb22d44/CZE-1528295206-proc-20180829135251.sqlite?versionId=56bb1e60-ff7c-407f-8041-3c628ef78db0">CZE-1528295206-proc-20180829135251.sqlite</a><br> </p> <p>SQLite database contains two primary tables. Table <em>nodes</em> and table <em>segments</em>, that resluts of selection and projection from the tables of the same name in primary db. Both tables are suitable for <em>searching nearest lines</em> task and <em>searching closest node of nearest line</em> task. </p> <pre><code class="language-sql">CREATE TABLE nodes ( gid INTEGER, part_gid INTEGER, node_type INTEGER, geom POINT ); CREATE TABLE segments ( gid INTEGER, node_gid_from INTEGER, node_gid_to INTEGER, frc TEXT, transition_time DOUBLE, computed_speed REAL, geom_length DOUBLE, geom LINESTRING ); </code></pre> <p>There are three more tables. Table <em>segments_rt</em> is a copy of table <em>segments</em>, that exclude loops in segments, hence it supports network routing task in SpatiaLite. Next table is <em>rt_network</em> (static graph generated from table <em>segments_rt</em> suitable for routing). The last one is table <em>virtual_rt_network</em>, that is an interface for routing query. </p> <p> </p>
Datasets generated by rurAllure project - promotion of rural museums and heritage sites in the vicinity of European pilgrimage routes
<p>These datasets have been generated as part of rurAllure project (funded by the European Union’s Horizon 2020 Research and Innovation programme under grant agreement no 101004887). Main goal of rurAllure is the promotion of rural museums and heritage sites in the vicinity of European pilgrimage routes: https://rurallure.eu/project/about/</p>
Data for: "A Route to Stabilize Uranium(II) and Uranium(I) Synthons in Multimetallic Complexes"
<p>Low valent uranium can be stabilized via an unprecedented mechanism involving intramolecular ligand migration:the two-and three-electron reduction of the oxo-bridgedU(IV)/U(IV)complex,[{(Ph3SiO)3(DME)U}2(O)], yields formal “U(II)”/U(IV) and “U(I)”/U(IV) complexes,via ligand migration and formation of uranium-arene δ-bond interactions,that can transfer up to threeelectrons tosubstrates by restoring the original ligand arrangement.</p>
Historical Occurrence of Antarctic Icebergs within Mercantile Shipping Routes and the Exceptional Events of the 1890s
<p>This is the dataset created for the Journal of Glaciology paper "<i>Historical Occurrence of Antarctic Icebergs within Mercantile Shipping Routes and the Exceptional Events of the 1890s</i>" by Robert Headland, Nick Hughes and Jeremy Wilkinson (<a href="https://doi.org/10.1017/jog.2023.80">doi:10.1017/jog.2023.80</a>). We have endeavoured to make the data as accessible as possible by providing it in a range of formats.</p><p>Please see the README.pdf for a detailed description of the files, and the paper for the dataset. Version 1.1 contains additional reports from newspaper archives.</p>
Companion data for RAT 3.0: Global Database, Test data, Parameter files and Routing Script
<p><a href="https://depts.washington.edu/saswe/rat/">Reservoir Assessment Tool version 3.0</a> is a scalable and user-friendly software platform to mobilize the global water management community. RAT uses satellite remote sensing data to monitor water surface area and water level changes in artificial reservoirs. It uses this information, along with topographical information (either derived from satellite data, or in-situ topo maps) to estimate the Storage Change (∆S) in the reservoirs. Additionally, RAT models the Inflow (I) and the Evaporation (E) of each reservoir. Finally, RAT uses the modeled I, and E, and estimated ∆S, to estimate the Outflow (O) from reservoirs. The datasets and files provided here are used by RAT 3.0 as default inputs to make it easy to set up and execute RAT for first-time users.</p> <p><strong>global_data.zip</strong> - It includes <a href="https://rat-satellitedams.readthedocs.io/en/latest/RAT_Data/GlobalDatabase/">Global Database</a> encompassing global elevation data, global reservoir and dam data, major river basins in the world and the river networks, flow direction file, and geoid model. It is used by RAT 3.0 as default input for easy execution for first-time users.</p> <p><strong>global_vic_params.zip</strong> - It contains <a href="https://zenodo.org/record/3475602">global VIC soil and domain parameters</a> for executing the hydrological model within RAT 3.0. It is considered a part of the Global Database but is packaged separately.</p> <p><strong>params.zip</strong> - It consists of all the default parameter files used by RAT 3.0 to execute the hydrological model within it and to execute RAT itself. </p> <p><strong>routing.zip</strong> - It consists of the Fortran code for <a href="https://vic.readthedocs.io/en/vic.4.2.d/Documentation/Routing/RunRouting/">the Routing model</a> for easy installation for users. </p> <p><strong>test_data.zip</strong> - It consists of data used by RAT 3.0 to test whether it has been installed and initialized properly in a user's system.</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>
Brainport, Urban driving, route request, VRU detection
<p><strong>Scenario description</strong>:</p> <p>Smartphone 3120 sends request, route 2 is being blocked by crowd (depending on run this changes), vehicle receives correct route and drives from west to east. Underway 2 VRU (3121 & 3122) crosses the road.</p> <p><strong>Session description</strong>:</p> <p>Complete use case: Request vehicle, choose route on CEMA and GeoFenching VRU detection with 2 smartphone detection</p> <p><strong>Datasets descriptions</strong>:</p> <p><strong>AUTOPILOT_BrainPort_UrbanDriving_DriverVehicleInteraction</strong>: Data extracted from the CAN of the vehicle</p> <p>Dataset Description This dataset contains e.g. throttlestatus, clutchstatus, brakestatus, brakeforce, wipersstatus, steeringwheel for the vehicle</p> <p><strong>AUTOPILOT_BrainPort_UrbanDriving_EAI2Mobile</strong>: Data from the service to the mobile</p> <p>Dataset Description This dataset contains information sent to the mobile about the Estimated Arrival time and position</p> <p><strong>AUTOPILOT_BrainPort_UrbanDriving_EnvironmentSensorsAbsolute</strong>: Data extracted from the vehicle environment sensors</p> <p>Dataset Description This dataset contains information about detected object, with absolute coordinates</p> <p><strong>AUTOPILOT_BrainPort_UrbanDriving_EnvironmentSensorsRelative</strong>: Data extracted from the vehicle environment sensors</p> <p>Dataset Description This dataset contains information about detected object, with relative coordinates</p> <p><strong>AUTOPILOT_BrainPort_UrbanDriving_IOT_CEMA_Message</strong>: Data from the service to the vehicle</p> <p>Dataset Description This dataset contains information from the Crowd Estimation and Mobility Analytics service</p> <p><strong>AUTOPILOT_BrainPort_UrbanDriving_IOT_FlowRadar_Message</strong>: Data from the vehicle to the service</p> <p>Dataset Description This dataset contains the GPS informaton (speed,position,heading) from the vehicle</p> <p><strong>AUTOPILOT_BrainPort_UrbanDriving_IotVehicleMessage</strong>: Data sent between all devices, vehicles and services</p> <p>Dataset Description Each sensor data submission is a Message. A Message has an Envelope, a Path, and optionally (but likely) Path Events and optionally Path Media. The envelope bears fundamental information about the individual sender (the vehicle) but not to a level that owner of the vehicle can be identified or different messages can be identified that originate from a single vehicle.</p> <p><strong>AUTOPILOT_BrainPort_UrbanDriving_IOT_VehicleStatus</strong>: Data sent from the vehicle to the service</p> <p>Dataset Description This dataset contains the current status of the vehicle</p> <p><strong>AUTOPILOT_BrainPort_UrbanDriving_PositioningSystem</strong>: Data from GPS on the vehicle</p> <p>Dataset Description This dataset contains speed,longitude,latitude,heading from the GPS</p> <p><strong>AUTOPILOT_BrainPort_UrbanDriving_SmartphoneGPS</strong>: Data sent by the mobile to the service</p> <p>Dataset Description This dataset contains the GPS informaton (speed,position,heading) from the mobile</p> <p><strong>AUTOPILOT_BrainPort_UrbanDriving_SmartphoneStatus</strong>: Data sent from the mobile to the service</p> <p>Dataset Description This dataset contains the current status of the mobile</p> <p><strong>AUTOPILOT_BrainPort_UrbanDriving_TaxiRequest</strong>: Data sent from the mobile to the service</p> <p>Dataset Description This dataset contains the requests for a taxi from the mobile phones</p> <p><strong>AUTOPILOT_BrainPort_UrbanDriving_Vehicle</strong>: Data from the CAN and sensors about the state of the vehicle</p> <p>Dataset Description This dataset contains a.o temperature and battery state of the vehicles</p> <p><strong>AUTOPILOT_BrainPort_UrbanDriving_VehicleDynamics</strong>: Data from the CAN and sensors about the state of the vehicle</p> <p>Dataset Description This dataset contains a.o accelerations and speedlimit of the vehicle, as observed from the CAN and the external sensors</p>
Brainport, Urban driving, route request, rerouting reception, VRU detection
<p><strong>Scenario description</strong>:</p> <p>Smartphone 3120 sends request, route 2 is being blocked by crowd (depending on run this changes), vehicle receives correct route and drives from west to east. Underway 1 VRU crosses the road.</p> <p><strong>Session description</strong>:</p> <p>Complete use case: Request vehicle, choose route on CEMA and GeoFenching VRU detection with 1 smartphone detection</p> <p><strong>Datasets descriptions</strong>:</p> <p><strong>AUTOPILOT_BrainPort_UrbanDriving_DriverVehicleInteraction</strong>: Data extracted from the CAN of the vehicle</p> <p>Dataset Description This dataset contains e.g. throttlestatus, clutchstatus, brakestatus, brakeforce, wipersstatus, steeringwheel for the vehicle</p> <p><strong>AUTOPILOT_BrainPort_UrbanDriving_EAI2Mobile</strong>: Data from the service to the mobile</p> <p>Dataset Description This dataset contains information sent to the mobile about the Estimated Arrival time and position</p> <p><strong>AUTOPILOT_BrainPort_UrbanDriving_EnvironmentSensorsAbsolute</strong>: Data extracted from the vehicle environment sensors</p> <p>Dataset Description This dataset contains information about detected object, with absolute coordinates</p> <p><strong>AUTOPILOT_BrainPort_UrbanDriving_EnvironmentSensorsRelative</strong>: Data extracted from the vehicle environment sensors</p> <p>Dataset Description This dataset contains information about detected object, with relative coordinates</p> <p><strong>AUTOPILOT_BrainPort_UrbanDriving_IOT_CEMA_Message</strong>: Data from the service to the vehicle</p> <p>Dataset Description This dataset contains information from the Crowd Estimation and Mobility Analytics service</p> <p><strong>AUTOPILOT_BrainPort_UrbanDriving_IOT_FlowRadar_Message</strong>: Data from the vehicle to the service</p> <p>Dataset Description This dataset contains the GPS informaton (speed,position,heading) from the vehicle</p> <p><strong>AUTOPILOT_BrainPort_UrbanDriving_IotVehicleMessage</strong>: Data sent between all devices, vehicles and services</p> <p>Dataset Description Each sensor data submission is a Message. A Message has an Envelope, a Path, and optionally (but likely) Path Events and optionally Path Media. The envelope bears fundamental information about the individual sender (the vehicle) but not to a level that owner of the vehicle can be identified or different messages can be identified that originate from a single vehicle.</p> <p><strong>AUTOPILOT_BrainPort_UrbanDriving_IOT_VehicleStatus</strong>: Data sent from the vehicle to the service</p> <p>Dataset Description This dataset contains the current status of the vehicle</p> <p><strong>AUTOPILOT_BrainPort_UrbanDriving_PositioningSystem</strong>: Data from GPS on the vehicle</p> <p>Dataset Description This dataset contains speed,longitude,latitude,heading from the GPS</p> <p><strong>AUTOPILOT_BrainPort_UrbanDriving_SmartphoneGPS</strong>: Data sent by the mobile to the service</p> <p>Dataset Description This dataset contains the GPS informaton (speed,position,heading) from the mobile</p> <p><strong>AUTOPILOT_BrainPort_UrbanDriving_SmartphoneStatus</strong>: Data sent from the mobile to the service</p> <p>Dataset Description This dataset contains the current status of the mobile</p> <p><strong>AUTOPILOT_BrainPort_UrbanDriving_TaxiRequest</strong>: Data sent from the mobile to the service</p> <p>Dataset Description This dataset contains the requests for a taxi from the mobile phones</p> <p><strong>AUTOPILOT_BrainPort_UrbanDriving_Vehicle</strong>: Data from the CAN and sensors about the state of the vehicle</p> <p>Dataset Description This dataset contains a.o temperature and battery state of the vehicles</p> <p><strong>AUTOPILOT_BrainPort_UrbanDriving_VehicleDynamics</strong>: Data from the CAN and sensors about the state of the vehicle</p> <p>Dataset Description This dataset contains a.o accelerations and speedlimit of the vehicle, as observed from the CAN and the external sensors</p>
Brainport, Urban driving, request route, VRU detection, route correction
<p><strong>Scenario description</strong>:</p> <p>Complete use case: Request vehicle, choose route on CEMA and GeoFenching VRU detection with 4 smartphone detections<br> Test detection of multiple VRUs close to each other and compare with camera detections.<br> Test GeoFence area of detection with different pedestrian walking paths (for pedestrian prediction)<br> Make comparison with GeoFenching enabled (runs 1-12) and with GeoFencing disabled (runs 13-25)</p> <p><strong>Session description</strong>:</p> <p>Smartphone 3120 sends request, route 2 is being blocked by crowd (depending on run this changes), vehicle receives correct route and drives from west to east. Underway 2 groups of each 2 VRU crosses, or walk alongside the road (see Test Plan Table 3 for exact walking patterns).</p> <p><strong>Datasets descriptions</strong>:</p> <p><strong>AUTOPILOT_BrainPort_UrbanDriving_DriverVehicleInteraction</strong>: Data extracted from the CAN of the vehicle</p> <p>Dataset Description This dataset contains e.g. throttlestatus, clutchstatus, brakestatus, brakeforce, wipersstatus, steeringwheel for the vehicle</p> <p><strong>AUTOPILOT_BrainPort_UrbanDriving_EAI2Mobile</strong>: Data from the service to the mobile</p> <p>Dataset Description This dataset contains information sent to the mobile about the Estimated Arrival time and position</p> <p><strong>AUTOPILOT_BrainPort_UrbanDriving_EnvironmentSensorsAbsolute</strong>: Data extracted from the vehicle environment sensors</p> <p>Dataset Description This dataset contains information about detected object, with absolute coordinates</p> <p><strong>AUTOPILOT_BrainPort_UrbanDriving_EnvironmentSensorsRelative</strong>: Data extracted from the vehicle environment sensors</p> <p>Dataset Description This dataset contains information about detected object, with relative coordinates</p> <p><strong>AUTOPILOT_BrainPort_UrbanDriving_IOT_CEMA_Message</strong>: Data from the service to the vehicle</p> <p>Dataset Description This dataset contains information from the Crowd Estimation and Mobility Analytics service</p> <p><strong>AUTOPILOT_BrainPort_UrbanDriving_IOT_FlowRadar_Message</strong>: Data from the vehicle to the service</p> <p>Dataset Description This dataset contains the GPS informaton (speed,position,heading) from the vehicle</p> <p><strong>AUTOPILOT_BrainPort_UrbanDriving_IotVehicleMessage</strong>: Data sent between all devices, vehicles and services</p> <p>Dataset Description Each sensor data submission is a Message. A Message has an Envelope, a Path, and optionally (but likely) Path Events and optionally Path Media. The envelope bears fundamental information about the individual sender (the vehicle) but not to a level that owner of the vehicle can be identified or different messages can be identified that originate from a single vehicle.</p> <p><strong>AUTOPILOT_BrainPort_UrbanDriving_IOT_VehicleStatus</strong>: Data sent from the vehicle to the service</p> <p>Dataset Description This dataset contains the current status of the vehicle</p> <p><strong>AUTOPILOT_BrainPort_UrbanDriving_PositioningSystem</strong>: Data from GPS on the vehicle</p> <p>Dataset Description This dataset contains speed,longitude,latitude,heading from the GPS</p> <p><strong>AUTOPILOT_BrainPort_UrbanDriving_SmartphoneGPS</strong>: Data sent by the mobile to the service</p> <p>Dataset Description This dataset contains the GPS informaton (speed,position,heading) from the mobile</p> <p><strong>AUTOPILOT_BrainPort_UrbanDriving_SmartphoneStatus</strong>: Data sent from the mobile to the service</p> <p>Dataset Description This dataset contains the current status of the mobile</p> <p><strong>AUTOPILOT_BrainPort_UrbanDriving_TaxiRequest</strong>: Data sent from the mobile to the service</p> <p>Dataset Description This dataset contains the requests for a taxi from the mobile phones</p> <p><strong>AUTOPILOT_BrainPort_UrbanDriving_Vehicle</strong>: Data from the CAN and sensors about the state of the vehicle</p> <p>Dataset Description This dataset contains a.o temperature and battery state of the vehicles</p> <p><strong>AUTOPILOT_BrainPort_UrbanDriving_VehicleDynamics</strong>: Data from the CAN and sensors about the state of the vehicle</p> <p>Dataset Description This dataset contains a.o accelerations and speedlimit of the vehicle, as observed from the CAN and the external sensors</p>
Brainport, Urban driving, fixed route, VRU detection
<p><strong>Scenario description</strong>:</p> <p>Only GeoFenching VRU detection with 3 smartphone detection<br> Test detection of multiple VRUs close to each other and compare with camera detections.<br> Test different size GeoFence area (20m wide x 50m long) of detection with different pedestrian walking paths (for pedestrian prediction) </p> <p><strong>Session description</strong>:</p> <p>Route is fixed, vehicle drives north - south. Underway 1 group of 3 VRU crosses the road.</p> <p><strong>Datasets descriptions</strong>:</p> <p><strong>AUTOPILOT_BrainPort_UrbanDriving_DriverVehicleInteraction</strong>: Data extracted from the CAN of the vehicle</p> <p>Dataset Description This dataset contains e.g. throttlestatus, clutchstatus, brakestatus, brakeforce, wipersstatus, steeringwheel for the vehicle</p> <p><strong>AUTOPILOT_BrainPort_UrbanDriving_EAI2Mobile</strong>: Data from the service to the mobile</p> <p>Dataset Description This dataset contains information sent to the mobile about the Estimated Arrival time and position</p> <p><strong>AUTOPILOT_BrainPort_UrbanDriving_EnvironmentSensorsAbsolute</strong>: Data extracted from the vehicle environment sensors</p> <p>Dataset Description This dataset contains information about detected object, with absolute coordinates</p> <p><strong>AUTOPILOT_BrainPort_UrbanDriving_EnvironmentSensorsRelative</strong>: Data extracted from the vehicle environment sensors</p> <p>Dataset Description This dataset contains information about detected object, with relative coordinates</p> <p><strong>AUTOPILOT_BrainPort_UrbanDriving_IOT_CEMA_Message</strong>: Data from the service to the vehicle</p> <p>Dataset Description This dataset contains information from the Crowd Estimation and Mobility Analytics service</p> <p><strong>AUTOPILOT_BrainPort_UrbanDriving_IOT_FlowRadar_Message</strong>: Data from the vehicle to the service</p> <p>Dataset Description This dataset contains the GPS informaton (speed,position,heading) from the vehicle</p> <p><strong>AUTOPILOT_BrainPort_UrbanDriving_IotVehicleMessage</strong>: Data sent between all devices, vehicles and services</p> <p>Dataset Description Each sensor data submission is a Message. A Message has an Envelope, a Path, and optionally (but likely) Path Events and optionally Path Media. The envelope bears fundamental information about the individual sender (the vehicle) but not to a level that owner of the vehicle can be identified or different messages can be identified that originate from a single vehicle.</p> <p><strong>AUTOPILOT_BrainPort_UrbanDriving_IOT_VehicleStatus</strong>: Data sent from the vehicle to the service</p> <p>Dataset Description This dataset contains the current status of the vehicle</p> <p><strong>AUTOPILOT_BrainPort_UrbanDriving_PositioningSystem</strong>: Data from GPS on the vehicle</p> <p>Dataset Description This dataset contains speed,longitude,latitude,heading from the GPS</p> <p><strong>AUTOPILOT_BrainPort_UrbanDriving_SmartphoneGPS</strong>: Data sent by the mobile to the service</p> <p>Dataset Description This dataset contains the GPS informaton (speed,position,heading) from the mobile</p> <p><strong>AUTOPILOT_BrainPort_UrbanDriving_SmartphoneStatus</strong>: Data sent from the mobile to the service</p> <p>Dataset Description This dataset contains the current status of the mobile</p> <p><strong>AUTOPILOT_BrainPort_UrbanDriving_TaxiRequest</strong>: Data sent from the mobile to the service</p> <p>Dataset Description This dataset contains the requests for a taxi from the mobile phones</p> <p><strong>AUTOPILOT_BrainPort_UrbanDriving_Vehicle</strong>: Data from the CAN and sensors about the state of the vehicle</p> <p>Dataset Description This dataset contains a.o temperature and battery state of the vehicles</p> <p><strong>AUTOPILOT_BrainPort_UrbanDriving_VehicleDynamics</strong>: Data from the CAN and sensors about the state of the vehicle</p> <p>Dataset Description This dataset contains a.o accelerations and speedlimit of the vehicle, as observed from the CAN and the external sensors</p>
Corpus of Pairwise Over-the-Phone Route Instructions (PROPRIS)
<p>This dataset is a corpus of German-language route instructions pairs of participants gave each other over-the-phone in an environment participants were unfamiliar in. It comprises 16 transcripts of conversations according to the HIAT guidelines, a QGIS project file containing all routes, demographics (age and gender), sense of direction data, BFI-60 aggregated values and a readme file.</p>
Supplementary Material for "Route Efficiency Assessment and Review of the Synthesis of β-Nucleosides via N-Glycosylation of Nucleobases"
<p>This is the external Supplementary Material for our publication "Route Efficiency Assessment and Review of the Synthesis of β-Nucleosides via <em>N</em>-Glycosylation of Nucleobases", which has been released as a preprint on <em>ChemRxiv </em>(https://doi.org/10.26434/chemrxiv.12753413.v1). The files in this record are additionally available from <em>ChemRxiv</em>.</p>
FIGURE 30 in Morphological and molecular data reveal the cryptic diversity among populations of Aegla paulensis (Decapoda, Anomura, Aeglidae), with descriptions of four new species and comments on dispersal routes and conservation status
FIGURE 30. Bayesian tree (TPM 2 uf + G) for Aegla species based on partial fragment of 16 S. Node numbers represent posterior probabilities (values <50 % are not shown), and divergence time in millions of years (my); * indicates the calibration points to molecular clock. The clade C proposed by Pérez-Losada et al. (2004) is highlighted in grey. The basin and sub-basin origin of the discussed species in this study are shown after the specific names.
FIGURE 24. A – L in Morphological and molecular data reveal the cryptic diversity among populations of Aegla paulensis (Decapoda, Anomura, Aeglidae), with descriptions of four new species and comments on dispersal routes and conservation status
FIGURE 24. A – L, proximal portion of fifth pereiopod showing coxa and sexual tube of long and narrow type. A – B, Aegla paulensis Schmitt, 1942 s. str., male topotype (MZUSP 34368). C – D, Aegla rosanae Campos Jr., 1998, male topotype (MZUSP 34369). E – F, Aegla vanini n. sp., male paratype (MZUSP 34372). G – H, Aegla japi n. sp., male paratype (MZUSP 34375). I – J, Aegla jaragua n. sp. male paratype (MZUSP 34378). K-L, Aegla jundiai n. sp., male paratype (MZUSP 13490). Bars: A – D, F – H, J = 200 µm; K, L = 100 µm; E, I = 500 µm.
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.