Calculates Centers‑of‑Gravity - warehouse locations that minimize transport costs - useful for supply chain network (re)design.
Shows how service distances are affected by the number of warehouses.
Offers extensive functionality: setup (semi-)fixed warehouse locations, limit capacities, group customers, model supply, location sensitivity analysis, and more.
Used by multinationals, logistics service providers, and consultancy firms, all over the world.
This web app - with demo data - is fully functional. We recommend to use browser Google Chrome. To run with your own data, you need to create an account.
“We have been using this Centers‑of‑Gravity Calculator for years. It’s better fit for purpose than the other tools we use(d) for this and we like the way Stelling Consulting is constantly improving the tool to make it even better.”
Head of Transport Solutions Design MLE MEA &
Network Design & Supply Chain Consulting Global Practice Lead DHL Supply Chain
Show map display settings
Show run options and parameters
Show help text, login form, intro
Map display settings
Customer/supplier size - display factor
Centers‑of‑Gravity size - display factor
Flow size - display factor
Set to zero to deactivate flow scaling
Hide roads, et cetera
Display Centers‑of‑Gravity as fixed-sized circles, instead of volume-sized circles
Fixed-sized Centers‑of‑Gravity color
Display geodesic flows between Centers‑of‑Gravity and customers
Display geodesic flows between Centers‑of‑Gravity and suppliers
Supplier flows color
Supplier flows arrow size
Set to zero to hide arrows
Scale arrows to flow size
Distance based customer coloring From green at 0 km, to red at
km (beyond this distance, from dark red to black)
Map tiles by Carto
Map tiles by ESRI
Map tiles by OpenStreetMap
Most changes in map display settings only take effect after running Calculate.
Predefined warehouse locations
Fixed customer-warehouse assignments
Fixed supplier-warehouse assignments
Supplier transport costs ratio
Show calculation aid transport costs ratio
Supplier transport (inbound) is - due to larger shipments - relatively less expensive than customer transport (outbound).
The supplier cost ratio expresses how much.
Supplier 'forces' pulling the Centers‑of‑Gravity are multiplied with this ratio.
On the map suppliers (white circles) appear relatively smaller than customers as well, as the same ratio is applied for circle sizes.
Formula LTL costs factor = %FTL costs = −0.7 × Shipmentsize2 + 1.63 × Shipmentsize + 0.078
Costs/km. No accurate input required as outcome is rate independent.
Expressed in KG, M3, pallet, loading metre, ...
Avg. shipment size
% FTL costs
Rate per qty
= Supplier rate per qty / Customer rate per qty
Each supplier delivers to its closest (or fixed) warehouse only (local-for-local)
Each supplier delivers to each warehouse
Each supplier delivers to each warehouse via its closest (or fixed) warehouse (2-echelon)
Location - Cost sensitivity analysis
-costs-increase-areas around each Center-of-Gravity (grey areas with dotted border) If a Center-of-Gravity is located at the area border, its inbound and outbound transport costs increase 5%
Number of Centers‑of‑Gravity
Present best solution out of
Save and Reload: data and settings are saved in local browser memory, so you can reload when logging in the next time.
Only functional if you have logged in.
Current sum of weighted distances
Lowest sum of weighted distances
Distance bin width (km)
Run scores chart
See also detailed output tables further below via this link
Optional input data ⇔ applying constraints
To demonstrate the advanced functionality, the demo data set contains optional input data, in input tables further below. Optional input data is only taken into account if you apply constraints ⇒ check "Show run options and parameters" just below the map.
Check constraint "Fixed customer-warehouse assignments" to assign customers to a warehouse.
Demo data: customers in UK/Ireland are assigned to the predefined Birmingham warehouse (optional field Warehouse_ID set to "Birmingham"), and customers in Spain/Portugal to the Madrid warehouse.
Check constraint "Customer groups" to have all customers within a group delivered by a single warehouse only.
Demo data: all 588 customers have optional field Group filled with a 2-letter ISO country code, so group means country in the demo: each country is delivered by one warehouse only.
Predefined warehouses table (optional)
Predefined warehouses become part of the solution.
Check constraint "Predefined warehouse locations" to activate predefined warehouses.
Demo data: one warehouse in Birmingham/UK (cannot move, field Move_limit set to 0) and one in Madrid/Spain (can move within a 200 km range around Madrid, field Move_limit set to 200).
Check constraint "Capacity limits" to limit warehouse throughput capacities.
Demo date: optional field Capacity is set to 482500 for Birmingham and 550000 for Madrid.
Suppliers table (optional)
Check Supply to activate supply.
Demo data: one supply location in Rotterdam/The Netherlands (supplies 71% total demand volume), and another one in Bologna/Italy (supplies 29% total demand volume).
Supply locations - like customers - pull warehouses. Centers‑of‑Gravity will tend to move towards those supply locations, as supply volumes are high compared to individual demand volumes. However, supplier transport is - due to larger shipments - usually relatively less expensive than customer transport. Supply parameter "supplier transport costs ratio" expresses how much less.
Supplier pull forces are multiplied with this ratio, as is their mapping size.
Under Supply parameters you can chose from three options how supply will flow via warehouses to meet demand.
Option “each supplier delivers to each warehouse” is the default option, meaning each supplier delivers to each warehouse, pro rata customer demand assigned to a warehouse.
Which also means that a supplier - unlike a customer - pulls all warehouses.
Though not mandatory, it is advised to express quantities as rounded numbers without thousands or decimal separators, and to filter out all records with zero quantity.
Use decimal point - not decimal comma - as decimal separator. Any commas in your data will be removed automatically. You can enter your data semicolon or tab separated. Tab separated data will be converted to semicolon separated data automatically.
Use the Batch Geocoder if you still need to retrieve latitudes and longitudes of your locations (city/postal code, country).
Warehouse_ID: free format, e.g. "Birmingham", used to assign a customer permanently to a predefined warehouse.
Group: free format, e.g. "UK", used to have all customers within a group delivered by a single warehouse only , the one that comes with the lowest sum of weighted distances for this group of customers. What group means, is up to you - often used is country. Capacity constraints may cause some customers of a group to be reassigned to another warehouse.
If you specify Warehouse_ID, the customer will be assigned to that warehouse, regardless Group.
Warehouse_ID: free format, e.g. "Birmingham", used to assign a supplier permanently to a warehouse. If set, then this supplier will not supply all warehouses, even if that supply option has been chosen.
Move_limit = 0 means a fixed warehouse location. Move_limit > 0 (in km, not miles!) means that the warehouse location may move within its Move_limit around its coordinates.
Capacity limits the demand that can be assigned to a warehouse. Capacity constraints (handled by a separate greedy algorithm) may cause customer groups being overruled.
Outcomes may vary, due to initial random locations. The more runs, the more likely the optimum solution will be found. Run several times to check if a solution reappears.
No restrictions apply in the 'warehouse-moving-process', so warehouses may end up in the middle of a lake.
Minimizing transport costs by locating warehouses in demand Centers‑of‑Gravity
Centers‑of‑Gravity are locations that bring minimized sum of weighted distances. Demand side: weighted distance is the as-the-crow-flies-distance from warehouse to customer multiplied by demand. For example, if a customer demand is 10 and this customer is at 25 km from the warehouse, then the weighted distance is 250 km. The sum of weighted distances of all customers is an indicator for transport costs. It is a relative figure. Supply side brings the sum of weighted distances between suppliers and warehouses. The supply-side is more complex than the customer-side as a single supplier may supply all warehouses, even via its closest warehouse, which means several 'pull forces' need to be considered. Centers‑of‑Gravity Calculator minimizes the sum of weighted distances of both demand and supply side.
Implicit assumption: transport cost = single rate/km × distance. So minimal kilometers come with minimal costs. This is only partly valid. For example, parcel rates are often distance independent within a region, FTL pallet rate/km is lower than LTL pallet rate/km, macro-economic imbalance cause direction-dependent rates.
Transport costs savings can be roughly estimated as: (1 - (sum of weighted distances TO BE network / sum of weighted distances AS IS network)) × AS IS transport costs.
Transport costs are only a part of supply chain costs.
The optimal number of warehouses and their locations are driven by many quantitative and qualitative factors such as (future) transport and warehousing rates, future demand, lead time requirements, inventory effects, supply chain risk/redundancy, contractual obligations.
Nevertheless, it is common practice to run a Centers‑of‑Gravity-analysis to get a view on what warehouse locations to consider, when (re)designing a supply chain network.
The quality of the core algorithms Centers‑of‑Gravity Calculator equals that of Llamasoft and Excel Solver, as it produces equal outcomes.
But Centers‑of‑Gravity Calculator ran much faster than Llamasoft (test 2017) and Excel Solver (test 2018): approx. 30 seconds (Centers‑of‑Gravity Calculator) versus 10-15 minutes (Llamasoft) and much more (Excel Solver; only if running for multiple CoG).