Study Area And Transport Zones

Every Mobility study starts with a territory.

Transport zones are the spatial units used by the model. People live in transport zones, activities happen in transport zones, and travel costs are computed between transport zones.

For a first run, you can use a small area around one city. For a project study, you can use a larger list of local administrative units and choose a smaller inner perimeter for the indicators.

A Small Study Area

For a first French example, use a city code and a radius:

transport_zones = mobility.TransportZones("fr-87085", radius=10.0)

This creates a small study area around Limoges. It keeps runtime lower than a large territory during the first workflow check.

Use this pattern when you want to test the workflow around one commune before preparing a full study perimeter. Choose the radius as a modelling assumption: it should keep the run tractable and avoid an artificial cut through important nearby origins or destinations.

Cross-Border Radius Searches

A radius search can only include countries for which Mobility has local administrative units. Mobility first builds the study area from local administrative units, then uses the countries found in that study area to select population, activity, survey, and public transport inputs.

For example, a radius around Strasbourg currently uses French local administrative units. German municipalities are not added, because Germany does not yet have local administrative units in Mobility. Downstream objects therefore do not request German population or activity data for that run.

When a neighbouring country is missing from a radius-based study area, treat the result as a modelling limitation of the current data coverage. To include that country, first add its local administrative units, then add the other data needed by the model.

Several Local Administrative Units

For a project study, pass a list of local administrative unit ids:

transport_zones = mobility.TransportZones(
    ["fr-74010", "fr-74133"],
    level_of_detail=1,
)

level_of_detail controls how detailed the generated transport zones should be. The current public values are 0 and 1. Zone detail affects routing time, aggregation, and how much spatial variation can be interpreted.

A practical sequence is:

  • use level_of_detail=0 for a first run, a broad diagnostic, or a faster sensitivity test,

  • use level_of_detail=1 when intra-communal differences matter for the study question,

  • move from 0 to 1 only after the first setup runs correctly.

More detailed zones can improve spatial interpretation, but they also increase routing work, file sizes, and the number of results to explain. As with any zonal transport model, the zoning system is part of the model specification: it can affect OD flows, modal indicators, and maps.

Mobility creates detailed zones from local administrative units and building-footprint density. Sparse generated zones can be merged before final zone ids are written. A zone is a modelling object used for population allocation, opportunity allocation, route-cost matrices, and result aggregation.

A Main Perimeter Inside A Larger Area

Many studies need two perimeters:

  • a large area for routing and cross-border trips,

  • a smaller area where the final indicators are read.

Use inner_local_admin_unit_id for the smaller reporting area:

transport_zones = mobility.TransportZones(
    lau_ids,
    level_of_detail=1,
    inner_local_admin_unit_id=inner_lau_ids,
)

This is useful when people can travel outside the main perimeter, but the study focuses on residents or zones inside it.

This is common for metropolitan and cross-border studies. Keep the routing area large enough to avoid cutting real trips too early, then use the inner perimeter for the indicators you report.

For a radius-based study area, inner_radius can be used in the same spirit: keep a larger routing area, then flag a smaller inner area for reporting.

Cut Out Areas That Should Not Become Zones

Use cutout_geometries to remove areas such as a lake:

transport_zones = mobility.TransportZones(
    lau_ids,
    cutout_geometries=lake_geometry,
)

This keeps the generated zones closer to the study area geography.

Use cutouts when a large geometry would otherwise create misleading zones, for example a lake, a mountain area, or another place where people do not live and transport-zone centroids would be hard to interpret.

Practical Checks

After creating transport zones, check:

  • the number of zones,

  • whether the main communes are present,

  • whether the inner perimeter is correct,

  • whether obvious no-population areas have been removed,

  • whether the level of detail is understandable for maps and tables,

  • whether zone centroids and network access points are credible for the shortest trips,

  • whether boundary zones are affecting the indicators you plan to report.

If runtime or interpretation becomes difficult, review the perimeter and zone detail before adding more modes or scenarios.

Main Objects

The main user-facing objects are:

  • mobility.LocalAdminUnits

  • mobility.TransportZones