CLLIB - A Benchmark Library for Two-Tier City Logistics

CLLIB Manual The CLLIB is a benchmark library of instance data of planning problems in two-tier city logistics for academic use. It contains 3,564 instances different, e.g., in the underlying geographical region, size and transportation means. The underlying urban regions are: District Oststadt of Karlsruhe, Germany (about 21,000 inhabitants and 5 km^2), Ingolstadt, Germany (about 141,000 inhabitants and 133 km^2), Munich, Germany (about 1.5 million inhabitants and 311 km^2). The instances involve between 10 and 500 demands, roadas well as rail-based transport and temporal as well as resource constraints like demand time windows (TWs), maximum waiting times and capacities of vehicles and locations. The CLLIB is generated using the open-source CLInstGen Framework coded in Python available via zenodo (https://doi.org/10.5281/zenodo.17307312). Sub-libraries are provided filtering the instances by the urban regions, by the number of demands, and by the demand types involved (details below). A library extension CLLIB-Analytics is provided to enable a proper evaluation of effects of single instance characteristics (details below). Creators: Julia Lange (RPTU Kaiserslautern-Landau, Germany) Johannes Gückel (Catholic University of Eichstätt-Ingolstadt, Germany) Pirmin Fontaine (Catholic University of Eichstätt-Ingolstadt, Germany) Timo Gschwind (RPTU Kaiserslautern-Landau, Germany) Latest version: September 2025 License: Creative Commons Attribution 4.0 International DOI: 10.5281/zenodo.17303876 Cite as: Lange, J., Gückel, J., Fontaine, P., & Gschwind, T. (2025). CLLIB - A Benchmark Library for TwoTier City Logistics [Data set, v1]. Zenodo. https://doi.org/10.5281/zenodo.17303876 Getting Started Download the .zip-file of your choice (CLLIB, any sub-library or CLLIB-Analytics) and unpack it. In the main folder, you can find a sub-directory 'Instances', which holds the instance files in JSON format, and two files 'instances_overview_*' (.xlsx and .json). They identically contain a database of all instances, their parameters and corresponding instance ids of the library or sub-library you downloaded. You can use them to further filter the instances, if required. 1 / 12 Distribution Centers Satellites Customer Locations Demands Transportation Network location (address, coordinates) location (address, coordinates) location (address, coordinates) origin distance matrix including both tiers  type maximum waiting time destination services with given routes, starting TW and fixed cost You can load instances from the 'Instances'-directory by instance id (end of every file's name) or by instance parameter value (abbreviations, part of every file's name). See details on value options and abbreviations below. Every instance file contains a nested dictionary holding the instance data. See its specific structure and key words below. City Logistics Context We refer to consolidation-based two-tier urban freight transportation, where a transport network is used to ship commodities between different locations in the system. Distribution centers are located in the outskirts of the city. Freight is transfered between the inter-regional and regional transport network there. Customer locations are located in dense urban areas. Satellite locations (short: satellites) with limited capacity represent (de-)consolidation points for freight within the dense area, where commodities are handed over between different types of delivery vehicles. The transport network defines the transportation options between these locations, which can be separated into two tiers (also named layers, echelons or levels). The first (also named outer) tier connects distribution centers and satellites, while the second (also named inner) tier connects satellites and customer locations. On each tier, a homogeneous fleet of vehicles with a certain capacity is operated. The transport network is represented in two ways, namely, (i) transportation links with given distances and vehicle capacities and (ii) transportation services with routes, capacities and fixed cost. Concerning the latter, services are operated by urban vehicles on the first tier and tours are operated by city freighters on the second tier. Demands with certain volume and time restrictions may flow inbound (e2c, from the external zone to a customer location), outbound (c2e, from a customer location to the external zone) and within the city (c2c, between two customer locations). They are not preassigned to distribution centers or satellites to handle them. We assume that deliveries and pickups at customer locations in the dense inner-city area are restricted by an inner-city access TW, in which all demand TWs are allocated. Nonetheless, travel activities on the first and second tier may take place before and after the inner-city access TW during the planning time horizon. The following table summarizes the entities and their corresponding parameters involved in the benchmark instances: 2 / 12 Distribution Centers Satellites Customer Locations Demands Transportation Network  region  direction tours with given routes and fixed cost maximum waiting time  handover time   maximum number of urban vehicles  volume portion of an urban vehicle   maximum number of city freighters  volume portion of a city freighter  size of parking area pickup TW (for c2e and c2c)   maximum demand volume per time period  delivery TW (for e2c and c2c)   maximum frequency (for rail satellites only) availability time (for e2c)     travel time to/from distribution centers  Instance Characteristics and File Names Instances can be classified according to different characteristics. The values and shapes of the characteristics are given by integers or encoded by abbreviations in the instance overview databases and instance file names, respectively. The following list is sorted in order of appearance in the instance file name. Name of the urban region (city) to consider ka_east: district Oststadt of Karlsruhe, ing: Ingolstadt, mun: Munich Number of customer locations 3 / 12 CLLIB: 10, 25, 50, 100, 200, 500 CLLIB-Analytics: 25, 50, 100 Customer locations replicate: identifier of ordered set of customer locations CLLIB: 1 (One sample of customer locations is used per number of customers.) CLLIB-Analytics: 1, 2, 3 (Three samples of customer locations are used per number of customers.) Satellite type: defines type of first-tier services and urban vehicles (abbreviations) stRO: road-based, stRA: rail-based (public transport-based) Satellite density: defines number of satellites (abbreviations) sdMI: minimal (one satellite per region) sdHA: halved (for each region, half as many as given, number randomly rounded if necessary) sdAG: as given (all given satellites of the urban area) Satellite density replicate: identifier for reduced set of satellites for sdAG: 1 (Given satellites represent one sample. No actual sample is taken.) for sdMI and sdHA in CLLIB: 1 (One sample of satellites is used per urban region.) for sdMI and sdHA in CLLIB-Analytics: 1, 2, 3 (Three samples of satellites are used per urban region.) Tour type: defines type of city freighters (abbreviations) ttBI: bike, ttCA: car Inner-city access TW width 120, 240 (minutes) Customer maximum waiting times distribution (abbreviations) cwtEQ: no, short and infinite waiting allowed uniformly distributed cwtOSH: no waiting allowed at any customer location (only short) cwtOME: short waiting allowed at every customer location (only medium) Customer waiting times distribution replicate: identifier of ordered set of customer waiting times CLLIB: 1 (One sample of customer waiting times is used per number of customers.) CLLIB-Analytics: 1, 2, 3 (Three samples of customer waiting times are used per number of customers.) Number of demands 4 / 12 always equal to number of customer locations Demand type distribution (abbreviations) dpOIN: only e2c (inbound) demands dpIO: 80% e2c (inbound) and 20% c2e (outbound) demands dpRE: 65% e2c (inbound), 20% c2e (outbound) and 15% c2c (inner-city) demands TW widths distribution (abbreviations) twEQ: short, medium and long TWs uniformly distributed (equal) twOSH: all TWs short in width (only short) twOME: all TWs medium in width (only medium) TW widths distribution replicate: identifier for ordered set of TW widths CLLIB: 1 (One sample of TW widths is used per number of demands.) CLLIB-Analytics: 1, 2, 3 (Three samples of TW widths are used per number of demands.) Demand size source (abbreviation) dsDE: for default distribution Demand size replicate: identifier for ordered set of demand sizes CLLIB: 1 (One sample of demand sizes is used per number of demands.) CLLIB-Analytics: 1, 2, 3 (Three samples of demand sizes are used per number of demands.) Instance identifier CLLIB: 1 to 3,564 CLLIB-Analytics: 10,000 to 103,149 File name structure: urbanRegion_numOfCustomerLocs-customerReplicate_ satelliteType_satelliteDensity-satDensityReplicate_tourType_accessTW_ custWaitTimeDistr-custWaitDistrReplicate_numDemands_demandTypeDistr_ twWidthsDistr-twWidthsDistrReplicate_demandSizeSource-demandSizeReplicate_instanceID.json Data Structure There exists one .json file per instance including a python dictionary holding the following information: {  "locations": {    "dc": {      "id": { 1 2 3 4 5 / 12        "address": string,        "coordinates": [longitutde, latitude]      }    }    "sat": {      "id": {        "address": string,        "coordinates": [longitutde, latitude],        "type": string,        "region": int, # if type = road        "maxWaitingTime": int, # in min        "maxNumUrbanVehicle": int,        "maxNumCityFreighter": int,        "sizeOfParkingArea": int, # in m^2, if provided        "maxDemVolumePerTime": int, # in cm^3, if provided        "maxFrequency": int # number of visits per hour, if type = rail      }    }    "cust": {      "id": {        "address": string,        "coordinates": [longitutde, latitude],        "maxWaitingTime": int # in min      }    }  },  "dima": [nested list of float], # loc. sorted acc. to id, in min, 9999.0 if link not existing  "accessTWWidth": int, # in min  "accessTW": [start, end], # in min  "timeHorizon": int, # in min  "demands": [    {      "origin": loc. id, # 0 indicates external zone      "destination": loc. id, # 0 indicates external zone      "direction": int, # 1 = e2c, -1 = c2e, 0 = c2c      "handoverTime": int, # in min      "volumeUrb": float, # between 0 and 1, set to 0 for c2c      "volumeCit": float, # between 0 and 1      "pickupTW": [float, float], # null, if not applicable      "deliveryTW": [float, float], # null, if not applicable      "availabilityTime": int, # set to 0 for c2e and c2c      "traveltimeDC": [float, float, ...] # as many floats as distribution centers, null, if not applicable    },    {}, ...  ],  "tours": [ # second/inner tier transportation 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 6 / 12 Note that id 0 is assigned to the external zone of the city. e2c and c2e demands have their origin and destination there, respectively. The location ids of distribution center, satellites and customer locations are in ascending order starting at 1. See details and consequences below.    {      "stops": [loc. id, loc. id, ...],      "fixedCost": float    },    {}, ...  ],  "services": [ # first/outer tier transportation    {      "stops": [loc. id, loc. id, ...],      "startTW": [int, int],      "fixedCost": float    },    {}, ...  ],  "characteristics": {    "Number of Customers": int,    "Customer Replicate": int,    "Satellite Type": str,    "Satellite Density": str,    "Satellite Density Replicate": int,    "Tour Vehicle": str,    "Instance Density": list, # not relevant for CLLIB and CLLIB-Analytics    "Time Horizon": int,    "Access TW": list, # list with start and end    "Access TW Width": int,    "Number of Demands": int,    "Demand Type Distribution": str, # str of tuple of demand type portions    "Demand Size Distribution": str,    "Demand Size Replicate": int,    "TW Widths Distribution": str, # str of tuple of TW widths distribution    "TW Widths Distr. Replicate": int,    "Customer Waiting Policy Distribution": str, # str of tuple of customer waiting policy distribution    "Customer Waiting Policy Replicate": int,    "Number of Tours": int,    "Number of Services": int,    "Neglect Feas.-Assur. Serv. Tours": False, # not relevant for CLLIB and CLLIB-Analytics    "Instance ID": int  } } 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 7 / 12 Name Instance Parameter Value Filter No. of Instances CLLIB-KA city: ka_east (Karlsruhe) 1,296 CLLIB-ING city: ing (Ingolstadt) 972 CLLIB-MUN city: mun (Munich) 1,296 CLLIB-Small number of customers/demands: 10, 25, 50 1,782 CLLIB-Medium number of customers/demands: 50, 100 1,188 CLLIB-Large number of customers/demands: 100, 200, 500 1,782 CLLIB-OnlyIn demand type distribution: dpOIN (only e2c demands) 1,188 CLLIB-InOut demand type distribution: dpIO (e2c (0.8) and c2e (0.2) demands) 1,188 CLLIBAllDemTypes demand type distribution: dpRE (e2c (0.65), c2e (0.2) and c2c (0.15) demands) 1,188 Sub-Libraries The following table provides an overview of the sub-libraries and their characteristics. CLLIB-Analytics The library extension CLLIB-Analytics is focused on sampling and statistical validity. Whenever sampling is required in the instance generation process, namely, for customer locations and a reduced number of satellite locations, for demand sizes and mixed TW widths, and for mixed maximum customer waiting times, 3 samples are drawn from the corresponding distributions or sets (creating replicate identifiers 1, 2 and 3). Each sample is combined with each other sample to create an instance. This facilitates the comparison of instances with exactly the same instance characteristic values. CLLIB-Analytics involves instances with a number of demands equal to 25, 50 and 100. All other instance characteristic values are varied like in the CLLIB. CLLIB-Analytics contains 93,150 instances, 32,400 each for Karlsruhe and Munich and 28,350 for Ingolstadt. CLLIB-Analytics is generated independent of the CLLIB instances and, thus, enables out-of-sample testing of models and methods developed and tuned by using the CLLIB. 8 / 12 Size Abbrev. XS S M L XL Probability of Occurrence 10% 20% 40% 20% 10% Size in cm^3 4,800 10,000 27,000 100,000 300,000 Handover Time in min 1 1 2 2 3 Vehicle Bike Car Truck Tram Capacity in m^3 2 4 11 21 Volume Portion XS 0.0024 0.0012 0.0004 0.0002 Volume Portion S 0.005 0.0025 0.0009 0.0005 Volume Portion M 0.0135 0.0068 0.0025 0.0013 Volume Portion L 0.05 0.025 0.0091 0.0048 Volume Portion XL 0.15 0.075 0.0273 0.0143 Internal Parameters and Rules Demand Sizes and Vehicle Capacities This data is based on research on real-world parcel and delivery vehicle sizes of the leading logistics service providers in the European market. For the integration of public transport, we refer to the scenario of adding one tram compartment to a regular passenger tram as given in several pilot projects. Demand sizes and their distribution as well as handover times Vehicle sizes and demand volume in proportional vehicle usage Demand TWs short TW: 15 min medium TW: 30 min long TW: length of inner-city access TW (corresponds to no restricting TW) All demand TWs are allocated within the inner-city access TW. Demand Availability Times For e2c demands, availability times are randomly determined according to the following rules: With a probability of 50%, the availability time is 0. With a probability of 50%, the availability time is chosen from a triangular distribution with lower 9 / 12