Source data

All input data are open. They are expected under %SourceDataDir%/NetworkModel_World, which the configuration exposes as %NetworkModelWorld_DataDir%. Prepared and intermediate results are written to %LocalDataProjDir%.

Population

The population grid is a GHSL population layer in World Mollweide at 1000 metre resolution. The version is set by ModelParameters/PopVersie, currently GHS_WUP_POP_E2025_GLOBE_R2025A_54009_1000_V1_0, and the cell size by ModelParameters/PopGridSize.

The raster itself is large enough that reading its values wholesale is a problem, which is why the configuration reads it lazily and immediately reduces it:

• big_raster is the raw raster, with a relation from every cell to its separated unit and to its functional area, both by point in polygon.
• sel_LandCells keeps only the cells that fall inside a separated unit. This is the land mask, and it is deliberately based on the polygon relation rather than on a population value, because a value based test caused problems in Canada.
• store_LandCells writes that selection to a .fss file, and LandCells reads it back. Everything downstream reads LandCells, never the raw raster.
• PopulatedCells is the further subset with population above zero, used for the settlement centroid calculation.

Each land cell carries its population, its geometry, and relations to separated unit, country and continent.

Settlements

Settlements come from the GHSL settlement model (SMOD), read as four shapefiles per settlement set:

Layer	Degree of urbanisation class	Type code in the model
villages	13	13
semidensetowns	22	22
towns	23	23
cities	30	30

Two settlement sets are configured, for 2000 and for 2020, each with its own population field. ModelParameters/Settlements_Set selects which one the analyses use; the default is SMOD_V1s6_opr_P2023_v1_2020. The four layers are combined into one all_settlements unit with a common identifier, label, population, type, country relation and continent relation.

Population weighted centroids

A settlement is represented in the network by a single point, and taking the geometric centroid of an irregular urban polygon would put that point in the wrong place. Instead the model computes a population weighted centroid: for every populated 1 km cell inside the settlement polygon, its coordinates are weighted by its population, and the weighted mean is taken. If that weighted mean happens to fall outside the polygon, which can happen for strongly concave shapes, the model falls back to centroid_or_mid, which guarantees a point inside the polygon.

The centroids are computed once per settlement type and stored next to the source data, together with the continent relation. This is step s4_Create_SettlementCentroids in MakeUnlinkedData.

Infrastructure

Road data are OpenStreetMap extracts from Geofabrik, one .pbf file per world region. The directory and the file date are set in ModelParameters/OSM_dir and ModelParameters/OSM_file_date. The full set of .pbf files is large, in the order of tens of gigabytes compressed.

Eight regions are read: Africa, Antarctica, Asia, Australia_Oceania, Central_America, Europe, North_America and South_America. Each region is read through GDAL, and its lines layer is written straight to a .fss file, because reading the same .pbf repeatedly is far slower than reading a stored GeoDMS file. This is step s5_Create_OSM_Continents_fss in MakeUnlinkedData.

When the continental road sets are assembled, Antarctica is dropped and Central America is unioned into North America, which brings the eight OSM regions back in line with the six continents used everywhere else.

From OSM tags to a car network

Per region, the stored lines are enriched:

• Road type. The highway tag is looked up in a table of 78 road types (Classifications/OSM/roadtype). Each type carries a car speed outside built-up areas, a car speed inside, a bike speed and a main road flag. A road is part of the car network when its inside car speed is above 1 km/h, which is how footpaths, cycleways, steps, construction and disused entries are excluded.
• Ferries. A line tagged route=ferry is a ferry. A line tagged route=ferry together with motor_vehicle=yes is a car ferry, and is given the ferry road type so that it becomes part of the routable network. Car ferries are the reason the continental networks do not fall apart at straits and archipelagos.
• Direction. oneway=yes sets the one direction flag. Note that this flag is deliberately overwritten with False when the link set is stored, because the digitisation direction in the source is not trusted yet.
• Speed. The other_tags field is searched for a maxspeed value among 15 standard values from 10 to 150 km/h. If one is found it is used. If not, the car speed of the road type is used.
• Main road class. Every line is classified into Main (above 70 km/h), Secondary (above 30 and up to 70 km/h), Tertiary (the rest of the car network) or Not_A_Road. A fifth class, Connector, is assigned later to the artificial links that attach origins and destinations to the network. This classification is what the flow and road length grids are split by.
• Connectable. Motorways and motorway links are marked as not connectable, so that origins and destinations are never attached directly to a motorway.

The Roads unit that leaves this step is the selection of lines that are part of the car network or are a car ferry. That is the input for Network construction.

Other inputs

• Country_Outlines, a GADM derived outline layer used to restrict grid cells to land during catchment generation.
• FUAs, the OECD functional urban areas, used as an exclusion mask.
• FunctionalAreas, the subnational zones described in Geography.
• snapraster_edgar, a fine WGS84 raster (built_s_wgs84_v1.tif) that defines the output grid for the modelled flows, at 100 metre resolution.

A note on the helper script

GetOSMnxFiles.py in the repository root is a small experiment with the osmnx Python package for pulling OSM features into a GeoPackage. It is not part of the production chain, which reads Geofabrik .pbf files directly through GDAL.