> ## Documentation Index > Fetch the complete documentation index at: https://docs.mapxagent.com/llms.txt > Use this file to discover all available pages before exploring further. # Development Suitability Baseline · Nairobi > Screen ecological, terrain and flood constraints in Nairobi, grade the remaining land, estimate carrying capacity and propose a development boundary with tiered controls. Development Suitability Baseline answers the first question of any growth plan: **where can this city build, and how much can it hold** once ecological, terrain and flood constraints are respected. It follows the two-part appraisal logic used in Chinese territorial planning — hard constraints first, suitability and carrying capacity second, boundary and tiered controls last. The Nairobi scenario as delivered: development control tiers drawn over ecological protection areas, protected areas and the 50 m riparian buffer ## What the scenario ships Opening the scenario imports eight prepared layers for the Nairobi window. Every layer comes from the [built-in datasets](/en/concepts/builtin-datasets) catalog with its default style, legend, source, licence and attribution attached. | Layer | Data | Role in the study | | - | - | - | | Road network | 52,642 OSM lines | Existing urban skeleton; reference for the boundary and for infill versus new growth | | Watercourses | 718 OSM lines | Source of the 50 m riparian buffer | | Administrative boundaries | 26 ADM3 units (geoBoundaries) | Attribution, summary tables and map labels | | Protected area constraints | 379 Overture features across Kenya | Part of the ecological exclusion | | DEM | Copernicus DEM GLO-30, 30 m (1,459–1,954 m) | Slope classes | | Land cover | Esri Sentinel-2 2020, 10 m, 9 classes (57% built-up) | Ecological classes and the existing built-up surface | | Flood hazard | WRI Aqueduct, 1 km | Flood avoidance line | | Population | GHS-POP, 1 km | Current population reference for the capacity comparison | *All layers come from the [built-in catalog](/en/concepts/builtin-datasets) with source and attribution attached, and they are not limited to Nairobi: the catalog provides the same datasets for other cities at the same specification — switch the study area, add the same entries, and this chapter's method chain transfers in minutes.* The layer order is the display order: points, then lines, then polygons, then rasters. All eight stay in the project for follow-up questions; only the surfaces you see in the legend above are styled as deliverables. ## How the study works The method is a chain of three planning questions. Each one maps onto deterministic [analysis](/en/concepts/analysis) tools, so every number in the report can be traced back to a run. | Stage | Question | What MapX runs | Output | | - | - | - | - | | 1. Screen the hard constraints | Which land is off-limits? | Slope, Reclassify, Buffer, Raster calculator, Overlay erase, Raster class area, Zonal statistics | Ecological protection mask and its polygons, the 50 m riparian buffer, constraint-area tables | | 2. Grade and size what remains | How suitable is the remaining land, and how many people can it carry? | Weighted overlay (equal weights by default), Reclassify, Grid at 1 km, Zonal statistics | Suitability classes 1–4, population per evaluation cell, class-area and capacity tables | | 3. Propose the boundary | Where should the development boundary run, and what tiers apply? | Raster to polygons, Overlay erase and dissolve, Zonal summary, Label anchors | Development control tiers (priority / managed / restricted), charts and a written report | In short, the study first subtracts the no-build space — ecological protection, steep slopes and the riparian buffer — from the study area, then grades the remaining land into four suitability classes with a weighted overlay and estimates carrying capacity per evaluation cell, and finally vectorises the result into three development control tiers (priority, managed, restricted) with charts and a report. The three stages share one deterministic operator chain: each stage's output layer is the next stage's input. ## Run it The screenshots below come from this scenario's reference workspace. Each step names the platform surface it uses, so you can follow the same path in your own project. **Suggested question:** *"Run a development-suitability study for Nairobi: screen the ecological, terrain and flood constraints, grade buildable land and carrying capacity, then propose a development boundary with tiered controls; deliver layers, charts and a report."* ### 1. Open the scenario Open **Scenarios** in the top menu, select this card and choose **Open scenario**. The whole bundle imports at once: every layer keeps its default style, legend, source and attribution, and the camera flies to the study area. Use the **Layers** panel to switch layers on and off before you type anything. The Nairobi scenario opened in a fresh project: the layer bundle imported, the Layers panel expanded, and the chat panel confirming the import with the suggested question ### 2. Ask the suggested question and review the plan Send the **suggested question** in the box above — or edit it first. [Plan mode](/en/concepts/plan-mode) turns it into a reviewable plan: the AI asks which admin units and constraints to use and whether the ecological mask is a hard exclusion, then writes the plan document — objective and scope, data inputs, method and pipeline, quality checks, risks, deliverables and execution. Every section is marked as **system evidence** or **evidence + judgement**, and the assumptions are listed before anything runs. The Nairobi plan document with the Plans panel on the left and the plan awaiting approval in the chat panel; plan sections and recorded decisions readable ### 3. Approve the plan and run the analysis Approving the plan starts a chain of deterministic [analysis](/en/concepts/analysis) tools: slope and reclassification, raster calculator masks for the ecological protection area, buffering along waterways, overlay erase for the hard exclusions, the 1 km evaluation grid and zonal statistics. The **Analysis** panel keeps the operator, inputs, parameters, status and result layer of every run, and the workflow graph in the centre visualises the whole chain, so each number in the report can be traced back to a step. The analysis view for Nairobi: the Analysis panel lists every operator run on the left, with the workflow graph in the centre ### 4. Style the result on the map The layers arrive styled, and the **layer style editor** lets you change the renderer, colours, opacity, outline, labels and legend without writing code. Here the development control tiers keep human-readable class names, labels come from an anchor layer, and the constraint layers stay translucent so the tiers remain the strongest signal. The style editor on a deliverable layer: classed-colour breaks and label settings, with the layer editing panel highlighted in red ### 5. Turn the result into charts and a report Any result can become a **[chart](/en/concepts/charts)** — donut, pie, bar, heatmap, combo and more — with palettes, axis options and the choice to pin it to the map. The **[report](/en/concepts/reports)** canvas then combines the map, the charts and the tables into one document you can preview, revise and export; the same run can also produce a Word report for a formal submission. A chart from this scenario in the chart editor, with the editing area highlighted in red The scenario report opened in the report canvas, with an executive summary, figures and embedded maps ## Example output The screenshots above come from one example run with the default settings on the shipped data. They show the shape of the deliverables, not what your run will return. A finished run hands back a named, reusable set of deliverables instead of a single map: * **Layers** — the buildable-land result, the suitability classes and the development control tiers, plus the constraint layers (ecological protection, protected areas, riparian buffer) as styled, legend-ready map layers. * **Tables** — class areas with an admin cross table, the population per evaluation cell, and the district-level summary. * **Charts** — the class-area composition, the constraints screened and the capacity ranking, each editable and pinnable. * **Report** — an assessment document that combines the map, the figures and the threshold table, ready to share or export. The layer names follow the run language, but the deliverable set is stable enough to plan a handover around. ## Related * [Scenarios](/en/concepts/scenarios) — the full catalog and how scenarios work * [Carrying Capacity Assessment](/en/concepts/scenarios/carrying-capacity-assessment) — the companion study for water, climate and flood constraints * [Land-use Conflict Screening](/en/concepts/scenarios/landuse-conflict-screening) — the same constraint logic applied to built-up land * [Built-in datasets](/en/concepts/builtin-datasets) — where every layer comes from * [Analysis](/en/concepts/analysis) — the tools behind each step * [Reports](/en/concepts/reports) — how the deliverable is assembled and exported This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.