Logis

The Problem

Which streets the collection truck should cover, how many trucks the operation actually needs and where to place a distribution centre are everyday questions in urban management, and they are almost never calculated. The methods have been in the operations research literature for decades, but they reach the practitioner through only two doors: proprietary routing software, priced beyond a small municipality's budget, or a researcher's script, which assumes a working Python environment and programming skills. Whoever works in QGIS, the tool installed in most city halls and consultancies, has nowhere to start.

Solid waste collection is the clearest case. Defining collection sectors and the order in which the truck runs the streets is an arc routing problem: what must be covered is the length of the street, not a set of stop points. That changes the formulation and puts it out of reach of the more common routing tools, which optimise visits to points. The outcome is familiar: sectors drawn by eye, overlapping itineraries and unproductive mileage nobody measures.

The Solution

Logis is a QGIS plugin that puts these calculations inside the software the practitioner already uses. It is organised into three modules, each built on its own base network, and all three offer the same three layers of capability: indicators, routing and facility location.

Urban Logistics: works on the municipal street network from OpenStreetMap, processed by a pipeline derived from GisBR. It covers network and demand indicators at city scale, including gravity accessibility to attractors and average delivery distance to the nearest depot.

Regional Logistics: works on the national highway databases (DNIT/SNV and geobr) and on state databases such as IDE-Sisema in Minas Gerais. This is the state and country scale: network density, share of paved road and identification of critical links, the ones whose removal splits the network in two.

Specialised Logistics: gathers the urban services whose routing is arc-based, starting with solid waste collection. It holds the sector design, the three classic traversal formulations (CPP, RPP and CARP), fleet sizing and the indicators that tell whether the resulting design holds up.

Key Features

25 algorithms in the Processing Toolbox: the plugin registers as a Processing Provider (logis), which means every analysis becomes an ordinary QGIS algorithm, chainable in the graphical modeller or callable from a script, with no bespoke interface to learn.

Arc routing: the three formulations waste collection requires, implemented over the street network: minimum cost Eulerian traversal covering every street (CPP), traversal restricted to the subset with active collection (RPP) and capacitated arc routing for a vehicle fleet (CARP).

Sector design and fleet sizing: the network is partitioned into contiguous, load-balanced collection sectors using farthest-first seeding, region growing and boundary segment swapping. From estimated volume, shifts and nominal capacity, the fleet algorithm returns the number of trucks required.

Indicators that audit the route: deadhead ratio (unproductive over productive mileage, per route and overall), balance of load and length across sectors, collection coverage per sector and distance to the landfill or destination point. These are what turn an itinerary into something verifiable.

Facility location: p-median through the Teitz-Bart heuristic, which minimises total demand-weighted travel cost, maximum covering location (MCLP) with a fixed number of facilities, and set covering (LSCP), which looks for the smallest number of facilities able to serve all demand.

Urban and regional network indicators: street density, connectivity through the α, β and γ indices, average circuity, edge betweenness centrality by sampling with an optional seed for reproducible results, a freight circulation restriction index and, at regional scale, density, paving and critical links over the SNV.

Three tabbed panels: the urban, regional and collection modules each have their own dock panel, organised by subject with a results pane fixed at the bottom. This is the way in for anyone who does not open the Processing Toolbox day to day.

No mandatory external dependencies: all graph and shortest path computation uses native QGIS classes (QgsGraph, QgsGraphBuilder, QgsGraphAnalyzer) and classic heuristics written in pure Python (Clarke-Wright savings, sweep, 2-opt, Teitz-Bart, Eulerian matching). OR-Tools comes in as an optional backend, lazily imported and falling back to the heuristics when it is not installed, which avoids conflicts with other plugins and removes the installation barrier for anyone who does not administer their own machine.

Technology Stack

Python PyQGIS QGIS Processing Framework QgsGraph / QgsGraphAnalyzer OR-Tools (optional) OpenStreetMap / Overpass API DNIT SNV GeoPackage / SQLite

Impact

Analyses that used to depend on proprietary routing software now fit inside the QGIS the practitioner already has installed, with input and output in SIRGAS 2000 (EPSG:4674) and a metric CRS only for intermediate distance and time computations. For a city hall, that means being able to test a sector design and measure the unproductive mileage it generates before contracting the operation, rather than after.

The plugin is at version 0.1.5, flagged as experimental, licensed under GPL-3.0, and validated by the author on QGIS 4.2 running on Ubuntu. The code is open on GitHub, and the same decision not to require an external dependency that makes installation possible on a locked-down machine also keeps the result auditable: the heuristics are in plain sight, in readable Python, not behind a black box.